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Preface 


This document is one of a set of Xerox internal documents which 
prescribe the interfaces between Print Service Processors and 
Image Output Terminals of high-end and low-end electronic 
printers. It is not a Xerox Standard, but rather a statement of 
generic specifications for these interfaces. 

High-end lOT interface 2.2 supersedes High-end lOT interface 
2.1, XNSGS 108702, February 1987 plus Addendum 1 as well as 
the OEM version, XNSGS 118702. There is no longer an OEM 
version. Version 2.2 includes all of the changes contained in 
Addendum 1, plus a number of changes which were requested 
subsequent to Addendum 1. All of these changes are to chapter 
6, "Client layer protocol." In addition, the handling of highlight 
color and grey scale are standardized in a new appendix E. There 
are no physical changes to the interface. 

Comments and suggestions on this document and its use are 
encouraged. Please address communications to: 

Xerox Corporation 
Printing Systems Division 
Printing Systems Administration Office 
701 South Aviation Blvd. 

El Segundo, California 90245 
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Scope 


This generic specification prescribes the required interface 
between the Print Service Processor (PSP) and the Image Output 
Terminal (lOT) of all high-end electronic printers, including those 
of the Distributed Printing and Reprographics Systems (DPRS) 
architecture. Refer to figure 1-1. For purposes of this 
specification, high-end includes any printer whose serial video 
data rate is equal to, or greater than, 10 Megabits per second 
and whose speed or functionality requires the synchronous data 
link prescribed herein. (In the remainder of this specification, it 
is to be understood that all references to PSPs, lOTs, and printers 
imply high-end. Also, the subject Interface will be referred to 
simply as the Interface when there is no likelihood of confusion.) 

This specification is applicable to all lOTs which print bit-map 
formats by means of a Raster Output Scanner (ROS) or by means 
of a line-marking array. This specification is not applicable to 
printing terminals which mark by means of optically or 
mechanically pre-formed characters. 

This specification accommodates video data transfer rates at the 
Interface up to 25 Megabits per second serial, and up to 200 
Megabits per second parallel. 

This specification defines the interchange of video data (bit-map 
data), command/status data, timing signals, and control signals, 
between one PSP and one lOT constituting a high-end electronic 
printer. 

This specification defines the layers of a three-layered 
architecture for command/status communications. 

This specification prescribes the interface signal repertoire, 
including the functional description of all the signals, the signal 
formats, and the timing relationships, where applicable. 

This specification prescribes the electrical and mechanical 
characteristics and parameters of the signal circuits, as well as the 
control procedures for effecting the transfer of information 
across this interface. 

This specification prescribes the interface circuit design and the 
required electronic and mechanical components (cables and 
connectors). 

This specification specifies grounding and shielding requirements 
associated with the interface. 

This specification defines the interface compatibility required 
between PSPs and lOTs of different performance capabilities. 

For purposes of this specification, an lOT is defined in terms of 
its functional entities as follows. 
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SCOPE 


An lOT includes: 

• Marking engine 

• Raster output scanner (ROS) or line marking array 

• Paper transport and delivery system 

• Machine controlier(s) 

• Electronic interface to Print Service Processor 

• DC power supply(s) 

• AC power interface and controls. 

An lOT may include: 

• User Interface 

• Maintenance interface 

• Video data buffer 

• Command buffer 

• Test pattern generator 

• Stand-alone diagnostics 

• Light-lens platen and optics 

• Document handler for light-lens copying 

• Stacker 

• Sorter 

• Billing meter(s). 

An lOT does not include: 

• Video generator, (character dispatcher/image generator) 

• Font storage 

• Data decompressor 

• Application processors 

• File storage facilities 

• Format processor or format-standard level shifter 

• Standard system interface (Ethernet). 
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Figure 1-1. System location of generic interface 
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Introduction 


The purpose of this specification is to provide a common 
implementation for the hardware and software interconnection 
between PSPs and lOTs of electronic printers. It is intended to 
be general enough to accommodate lOTs with different 
performance capabilities, different line scanning formats, and 
different marking technologies. This specification requires that 
each PSP be compatible, at this interface, with all lOTs of 
performance equal to or less than its peer lOT, within the 
bounds of high-end performance (chapter 1). This specification 
is intended to be sufficiently specific and complete so as to allow 
such interconnection with no significant hardware or software 
changes related to the interface functions. However, each PSP 
and each lOT will have some unique parameters which must be 
made known to each other. This specification identifies these 
parameters, but does not prescribe the method by which they 
are introduced into the system. 

The lOT Interface is the path by which bit-maps of the images to 
be printed reach the lOT. The interface embodies the 
communications by which the electronic image generation 
functions of the PSP are synchronized with the real-time 
requirements of the marking engine, and by which the PSP 
controls the operational states of the IQJ. The command/status 
interface also provides the means for transferring blocks of non¬ 
image data between PSP and lOT (and vice-versa), and for 
invoking and/or running lOT diagnostic routines from the PSP. 

The transfer of an image is viewed as a real-time process 
between PSP and lOT, with the lOT as the source of 
synchronization for line and page generation. The fast scan 
and/or slow scan mechanisms of the marking engine may or may 
not be decoupled in time from the interface transfer. In any 
case, the lOT defines a standard image frame, and it is the 
responsibility of the lOT to align this frame relative to the 
elements of the marking engine and to the output paper. It is 
the responsibility of the PSP to align the image within the 
standard image frame. Control of marking outside of the 
standard image frame is an lOT responsibility and is not 
supported at the interface. 

The primary format for video data at the interface is 8-bit parallel; 
however, a serial mode is also provided for video data rates 
under 25 Megabits per second. The PSP provides a return video 
clock in both cases. In the serial mode, the use of the return 
video clock in the lOT is optional. 

Application of this Generic Interface Specification to some 
complex printing arrangements which have been proposed may 
not be feasible because of the combined constraints imposed on 
data rate, grounding, and shielding. 

The PSP and lOT of a printer may be co-packaged with minimal 
separation in a single cabinet, or may be contained in physically 
separated individual cabinets. This specification prescribes the 
interconnecting cable to be used, includes a timing tolerance 


HIGH-END lOT INTERFACE 2.2 


2-1 



INTRODUCTION 


analysis for the reclocked video data transmission modes, and 
specifies jitter limits for the unreclocked mode. 
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Interface signals functional 

description 


Note: In the following text, boldface is used to indicate the 
actual signal as it appears at the interface, as distinguished from 
use of the term as an adjective or in reference to the function 
performed. 


3.1 Imaging interface 


3.1.1 Imaging conventions 

The imaging interface signals are described with respect to the 
following spatial imaging conventions, which must be followed 
by all PSPs and lOTs. The standard image frame is a rectangular 
image space whose sides are parallel to the slow scan and fast 
scan directions of the lOT, and whose dimensions are equal to 
the dimensions of the largest size paper which an lOT can 
accommodate, plus registration tolerance in the respective 
directions. Figure 3-1 shows the generalized relationships when 
viewing the imaged side of the paper. In the slow scan 
direction, the total paper registration error (plus and minus) 
comprises the registration tolerance. In the fast scan direction, 
there is an additional image generation tolerance, specified in 
chapter 4, to allow for priming and flushing the video processing 
channels in the PSP. Each lOT design must specify its own 
unique standard image frame(s). The first pixel delivered to the 
standard image frame must fall at the lower left hand corner, as 
viewed from the start-of-scan edge, and the fast scan and slow 
scan must proceed upward and to the right, respectively. 
(Although long-edge feed is shown in figure 3-1, no inference 
should be made that this is a requirement.) 

It is the responsibility of the iOT to align the elements of the 
marking engine so that the maximum size paper is registered in 
the center of the standard image frame in both directions, within 
the limits of the registration errors. It is the further responsibility 
of the lOT to register smaller size paper according to one of the 
modes listed below, which must be known to the PSP. Leading 
and trailing refer to the slow scan direction. Start-of-scan, end-of- 
scan, and center refer to the fast scan direction. 

PAPER REGISTRATION MODES 

A. Leading-edge, Start-of-scan 

B. Leading-edge, Center 

C. Leading-edge, End-of-scan 

D. Trailing-edge, Start-of-scan 

E. Trailing-edge, Center 

F. Trailing-edge, End-of-scan 

Registration of the respective edges (or center) is with respect to 
the ideal location of the corresponding edges (or center) of the 
maximum size paper. Note that with gapless printing, there are 
no paper registration errors in the slow scan direction. 
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Page video is that image information which is intended to appear 
on paper. It is the responsibility of the PSP to align the page 
video within the standard image frame so that it is imaged on 
paper for any combination of paper size and registration mode. 
The PSP may offset the image forward or backward in the slow 
scan direction so that some of the original page video, at the 
leading or trailing edge, is not actually transmitted to the lOT 
and, thus, is not imaged. If a PSP cannot offset images in this 
manner, the desired result may be obtained by requesting that 
the lOT define its standard image frame to be larger in the slow 
scan direction by the total amount of leading and trailing offset 
desired. In this case, the page video in the offset area is actually 
transmitted to the lOT, but is imaged beyond the leading or 
trailing edge of the paper. 

When edge marking is employed, the PSP may designate page 
video to the outer limits of the expected position of the paper, 
i.e., including the registration errors. This is done to guarantee 
that the desired image falls at the extreme edge of the paper. If 
the PSP's fast scan image registration tolerance is such as to 
preclude reaching the edge of paper (at either end), lOT 
registration adjustment of the standard image frame can achieve 
the desired result. With edge marking, it is likely that some page 
video will fall beyond the edge of the paper. 

Note that an lOT may implement more than one Standard Image 
Frame. The procedure for changing from one to the other Is lOT 
specific. See also application notes for information type, 
'"MediaMatrix," under lOT status message, 'MotConfiguration,'' in 
section 6.3.3. 


3.1.2 Page sync 


This signal is generated in the lOT and sent to the PSP. It 
defines each slow scan imaging interval to the PSP in real time. 
Its primary purpose is to synchronize the delivery of a standard 
image frame worth of video data to the lOT. The PSP must 
deliver a standard Image frame worth of video data for each page 
sync received. The duration of page sync defines the standard 
image frame in the slow scan direction. The beginning of page 
sync must correspond to the leading edge of the standard image 
frame, and the end of page sync must correspond to the trailing 
edge of the standard image frame. The PSP must be capable of 
delivering scan lines containing page video starting with the first 
line sync following the beginning of each page sync. This 
capability is required to accomplish edge marking at the leading 
edge of paper, when the paper is leading edge registered. 

An exception to the above definition is necessary for gapless 
printing. In this case, page sync must end prior to the end of 
the standard image frame currently being delivered by the PSP. 
The PSP must continue to deliver scan lines for the current 
standard image frame until the beginning of the next page sync 
occurs, and must then deliver the first scan line of the next 
standard image frame with the next line sync. For this purpose, 
the PSP must know that the lOT Is a gapless printer. 

(Section 6.4.2, "Message sequencing and timing requirements," 
defines the relationship between certain command/status 
messages and page sync. Section 6.4.4, "Page sync regimen," 
discusses the rules for appearance of page sync at the physical 
interface.) 
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3.1.3 Line sync, video clocks, video data 

To accommodate the anticipated speed and functional 
requirements of the various electronic printer products, two 
different interface modes are prescribed for this set of signals, as 
follows. 

3.1.3.1 Eight-bit parallel mode 
(refer to figure 3-2) 

This is the principle interface mode, designed to accommodate 
total video data rates up to 200 Mbps. In this mode, the video 
clock is a byte clock with maximum frequency of 25 Mhz. This 
clock is returned to the lOT, along with the parallel video data 
clocked out of the PSP, and is used to reclock this parallel video 
data at the lOT before it is used for marking. In order to achieve 
the desired degree of compatibility across the product line, all 
PSPs which implement this parallel interface must also support 
the Serial Mode at 25 Mbps (refer to section 3.1.3.2). 

Line sync This signal is generated in the lOT and sent to the PSP. It 
defines each fast scan imaging interval to the PSP in real time. It 
helps to synchronize the delivery of a scan line worth of video 
data to the lOT. The PSP should re-synchronize on every line 
sync, so as not to propagate the effects of any loss of 
synchronism. Line sync must be present during every page sync 
and may be present during interpage gaps and during other non¬ 
imaging states of the lOT. The positive transition of line sync 
marks the nominal start of the standard image frame in the fast 
scan direction (the exact start is defined below). The negative 
transition of line sync marks the end of the standard image 
frame. 

Byte clock This signal is generated in the lOT and sent to the PSP. It 
defines the occurrence and time span of each byte interval 
during which eight pixels are transmitted in parallel from the PSP 
to the lOT. Byte clock occurs in bursts, beginning a specified 
time after the beginning of line sync, and ending with the falling 
edge of line sync. (An allowable overrun into line sync dead¬ 
time is defined in section 4.2.1.) The beginning of the byte 
clock burst marks the beginning of the standard image frame in 
the fast scan direction. Byte clock must be transmitted 
whenever line sync is transmitted. The quiescent state of byte 
clock is logic level 0. The average period of the byte clock 
cycles during a line sync period may vary slightly from scan to 
scan, according to the design requirements of the lOT. 

Return byte clock This signal is derived from byte clock in the PSP and is 

transmitted from the PSP back to the lOT, along with video data. 
It is intended that return byte clock should undergo the same 
propagation delay as video data, so as to be directly usable for 
reclocking video data at the lOT. (Refer to section 7.2 for 
analysis of timing tolerances.) 

Video data In this mode, there are eight parallel video data signals 

designated video data 0 through video data 7. These signals are 
generated in the PSP using byte clock, and sent to the lOT. The 
earliest through latest pixels of an 8-pixel octet of scan line data 
must be placed on video data lines video data 7 through video 
data 0, respectively. The full content of the scan-line (defined by 
the standard image frame) must be delivered by the PSP. It is 
the responsibility of the PSP to align the page video within the 
standard image frame so as to account for the current paper size 
and the paper registration mode being used by the lOT. For all 
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pixel positions which precede or follow page video within the 
standard image frame, the PSP must deliver pixels with the image 
background level. Signal lines video data 0 through video data 7 
must also be placed at the logic level corresponding to image 
background, during all line sync dead times and during all page 
sync dead times (except with gapless printing, refer to section 
3.1.2), including machine states when page sync is inactive and 
including machine states when the video generator is inactive. It 
is the responsibility of the lOT to manage the state of the 
marking means outside of the standard image frame. 

An entire standard image frame of background level video will be 
delivered when a dead cycle is requested at the Client Layer 
(refer to chapter 6). 

3.1.3.2 Serial mode, reclocked and un-reclocked 
(refer to figure 3-3) 

When the total video data rate at the Interface is not greater than 
25 Mbps, the serial interface may be used. In this mode, video 
data is clocked out of the PSP, transmitted serially to the lOT, 
and either used directly for marking without reclocking, dr 
reclocked at the lOT for functional or signal quality reasons 
before marking. In this mode, the video clock is a pixel clock. 

Line sync This signal is generated in the lOT and sent to the PSP. It 
defines each fast scan imaging interval to the PSP in real time. It 
helps to synchronize the delivery of a scan line worth of video 
data to the lOT. The PSP should re-synchronize on every line 
sync, so as not to propagate the effects of any loss of 
synchronism. Line sync must be present during every page sync 
and may be present during interpage gaps and during other non¬ 
imaging states of the lOT. The positive transition of line sync 
marks the nominal start of the standard image frame in the fast 
scan direction (the exact start is defined below). The negative 
transition of line sync marks the end of the standard image 
frame. 

Pixel clock This signal is generated in the lOT and sent to the PSP. It 
defines the occurrence and time-span of each pixel as it is 
intended to be received by the lOT. It is used to clock the video 
data out of the PSP for transmission across the Interface. Pixel 
clock occurs in bursts, beginning a specified time after the 
significant transition of line sync, and ending at the falling edge 
of line sync (an allowable overrun into line sync dead-time is 
defined in section 4.2.2). The beginning of the pixel clock burst 
marks the beginning of the standard image frame in the fast scan 
direction. The quiescent state of pixel clock Is logic level 0. The 
average period of the pixel clock cycles during a line sync period 
may vary from scan to scan, according to the design 

requirements of the lOT. 

Return pixel clock This signal is derived from pixel clock in the PSP and Is 

transmitted from the PSP back to the lOT along with video data. 
It is intended that return pixel clock should undergo the same 
propagation delay as video data so as to be directly usable for 
reclocking video data at the lOT (refer to section 7.2 for analysis 
of timing tolerances). For purposes of product line compatability 
all PSPs which implement the serial mode must implement return 
pixel clock. lOTs may or may not use return pixel clock, 
depending on their design requirements. 

Video data This signal is generated in the PSP and sent to the lOT. It is 

generated in the PSP using pixel clock. The full content of the 
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scan line (defined by the standard image frame) must be 
delivered by the PSP. It is the responsibility of the PSP to align 
the page video within the standard image frame, so as to account 
for the current paper size and the paper registration mode being 
used by the lOT. For all pixel positions which precede or follow 
page video within the standard image frame, the PSP must deliver 
pixels with the image background level. The video data signal 
line must also be placed at the logic level corresponding to 
image background during all line sync dead times, and during all 
page sync dead times (except with gapless printing), including 
machine states when page sync is inactive and including machine 
states when the video generator is inactive. It is the 
responsibility of the lOT to manage the state of the marking 
means outside of the standard image frame. When a PSP with a 
parallel interface is used in the serial mode, the video signal must 
be placed gn the video data 7 interface path. 

An entire standard image frame of background level video will be 
delivered when a dead cycle is requested at the client layer (refer 
to chapter 6). 


3.2 Control interface 


3.2.1 Command 


Command is generated in the PSP and sent to the lOT in the 
physical layer of the multi-layer command/status function (refer to 
chapter 5). This is a message formatted signal carrying command 
information to the lOT, necessary for managing the printer in its 
various running modes. It is also suitable for downloading 
software from the PSP to the lOT. The transmission protocol is 
HDLC (High-level Data Link Control protocol). This signal must 
be encoded so as to allow clock recovery from the serial data 
stream at the receiver. 


3.2.2 Status 


Status is generated in the lOT and sent to the PSP in the physical 
layer of the multi-layer commiand/status function (refer to chapter 
5). This is a message formatted signal which carries status 
information from the lOT, necessary for management of the 
printer in its various running modes. It is also suitable for 
uploading blocks of information from lOT memory, upon 
command from the PSP. The transmission protocol and 
encoding requirements are the same as for Command. 


3.2.3 Power control 


This is a special circuit from the PSP to the lOT, which can cause 
the main AC power in the lOT to be turned on or turned off, 
provided that the lOT has been placed in a ''Remote Power 
Control" mode. (The lOT must have an Emergency Power Off 
switch which can override this remote power control.) This 
circuit provides DC power from a PSP power source to a control 
actuator in the lOT, and includes a return path to the PSP in 
which the primary control elements are located. The control 
actuator in the lOT operates a power actuator which switches the 
AC power mains in the lOT (refer to section 8.4). 
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The power on/off condition of the lOT may be monitored by 
detecting in the PSP whether or not the status signal source has 
its normal DC power (refer to section 8.5). There is no separate 
interface circuit to monitor the power on/off status of the lOT. 

It is the individual responsibility of the PSP and the lOT to 
manage their own shutdown modes. However, advance warning 
of a non-emergency shut-down initiated by the PSP must be sent 
to the lOT (refer to chapter 6, PspMetaReset and 
lotConfiguration). 


3.3 Alternate imaging modes 


Conventions for handling trilevel highlight color imaging and grey 
scale imaging are prescribed in appendix E. 
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Figure 3-1. Spatial relationships for imaging 
(viewing imaged side of paper) 
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Characteristics of imaging 
interface signals 


The following nomenclature conventions have been adopted for 

the Imaging Interface signals described below: 

Signal Name + A single rail of the differential signal; 
high = iogic 1 

Signal Name - A single rail of the differential signal; the 
complement of Signal Name + 

Logic 1 The most positive signal voltage level: 

typically -0.8v when referenced to signal 
ground (logic ground) 

Logic 0 The most negative signal voltage level: 

typically -1.8v when referenced to signal 
ground (logic ground). 


4.1 Page sync (refer to figure 4-1) 

The principal description of page sync which follows applies to 
lOTs which utilize cut sheet paper. Gapless printers which utilize 
a continuous paper web are accommodated by exception, also 
described below. 

Page sync is a binary signal whose true state delineates the slow 
scan dimension of the standard image frame to the PSP. Thus, 
the rising edge (positive transition) of page sync indicates to the 
PSP that it must start delivering the first scan line of the standard 
image frame. Positive transitions are from the 0 logic level to the 
1 logic level, as observed on the positive rail of the balanced 
interface connection (the negative rail will have the logical 
inverse transitions). Page sync is considered to be true when it 
is in the logic 1 state, as defined above. Both the rising and 
falling edges of page sync must be synchronized to the falling 
edges of line sync with a tolerance of ±50 nanoseconds at the 
lOT end of the interface cable. This will guarantee that the first 
rising edge of line sync following the rising edge of page sync 
can be reliably detected by the PSP after suffering propagation 
skew. It also defines the minimum page sync dead-time to be 
equivalent to one line sync interval. Page sync may recur 
regularly or irregularly (refer to section 6.4.4, "Page Sync 
Regimen," and the operating sequences in section 6.5). In either 
case, the lOT design must specify the minimum page time, i.e., 
the minimum time between any two successive rising transitions 
of page sync. The quiescent state of page sync is the 0 logic 
level on the positive rail of the balanced interface connection. 

For gapless printing lOTs the standard image frames are 
contiguous and the rising edges of page sync mark the 
boundries in the slow scan direction. Therefore, the falling edge 
of page sync must occur within the standard image frame (refer 
to figure 4-2). The minimum dead time interval must be the 
same as that for the cut sheet case. A PSP must know when it is 
connected to a gapless printing lOT, and, in that case, must 
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continue to deliver standard image frame scan lines during page 
sync false, until the end of the standard image frame is reached. 
This is determined either by line count or by occurrence of the 
next positive transition of page sync. The first scan line of the 
next standard image frame must be delivered with the first 
positive transition of line sync following the page sync transition. 
The PSP must notify the lOT of what slow scan dimension is 
appropriate for the standard image frame. 


4.2 Line sync^ video clocks, video data 


4.2.1 Eight-bit parallel mode (refer to figure 4-3) 

Line sync This is the primary timing reference for this group of signals. 

Line sync is a binary signal whose true state delineates the fast 
scan dimension of the standard image frame to the PSP. Thus, 
the rising edge (positive transition) of line sync indicates to the 
PSP that it must prepare to deliver the first byte of the standard 
image frame. Positive transitions are from the 0 logic level to the 
1 logic level, as observed on the positive rail of the balanced 
interface connection (the negative rail will have the logical 
inverse transitions). Line sync is considered to be true when it is 
in the logic 1 state, as defined above. The actual duration of line 
sync true must include all of the byte clocks which constitute the 
standard image frame, plus a minimum of 120 nanoseconds 
preceding the first transition of byte clock (refer to the next 
section). Line sync may recur regularly or irregularly. The dead¬ 
time interval must be a minimum of 300 nanoseconds, so as to 
provide a margin at the lOT between the end of return byte 
clock and the beginning of byte clock for the next scan line. 
The quiescent state of line sync is the 0 logic level on the 
positive rail of the balanced Interface circuit. 

Byte clock This Is a long burst of square waves whose positive transitions are 
used to clock the video data out of the PSP eight pixels at a time 
in parallel. The clock period, Tbc/ rnust be specified by the lOT 
and must not be less than 40 nanoseconds. It will normally be 
derived from an internal lOT pixel clock. The duty cycle must be 
50% ±5% at the input to the line driver in the lOT. Rising edges 
(positive transitions) are from the 0 logic level to the 1 logic 
level, as observed on the positive rail of the balanced interface 
connection. The delay between the positive transition of line 
sync and the first positive transition of byte clock must not be 
less than 120 nanoseconds at the input to the line driver at the 
lOT interface, so as to guarantee at least 100 nanoseconds delay 
at the output of the line receivers at the PSP interface. The 
number of cycles of byte clock which constitute a scan line of 
the standard image frame is equal to the number of 8-pixel 
octets of video data, which represent the largest size paper that 
the lOT will accommodate plus the lOT's paper registration 
tolerance, plus an additional 24 to 48 byte clocks for PSP image 
registration tolerance. The PSP may be designed to divide the 
extra 24 to 48 byte clocks between the beginning and end of 
scan, as needed. This division is to be fixed for any given PSP 
design and not alterable from line to line or from page to page. 
If line sync dead-time is greater than 300 nanoseconds, an lOT 
may continue byte clocks into the dead-time interval of line 
sync, but byte clock cycles must terminate at least 300 
nanoseconds before the next rising edge of line sync. Fractional 
byte clocks are not allowed. The true state must always be a full 
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half cycle. The quiescent state of byte clock is logic level 0 on 
the positive rail of the balanced interface circuit. 

Return byte clock This is a binary signal derived from byte clock at the PSP. At the 
input to the interface line drivers in the PSP, it must be phased 
so that the positive transitions are centered in the video data 
byte interval with a tolerance of ±5 percent. This will guarantee 
that video data can be reliably reclocked at the output of the 
line receivers in the lOT. Positive transitions are from the 0 logic 
level to the 1 logic level, as observed on the positive rail of the 
balanced interface connection. Return byte clock must have 
essentially the same epoch as byte clock, and exactly the same 
number of cycles. 

Video data These are eight binary signals, each of which follows the same 
polarity convention; logic level 0 on the positive rail of the 
balanced interface (logic level 1 on the negative rail) corresponds 
to image background level. The nominal time period of each 
byte of video data is determined by the period of byte clock, as 
received at the PSP. All of the video data signals must be in 
phase with each other (and with return byte clock, as described 
above) at the input to the line drivers at the PSP interface. The 
timing relationship between return byte clock and each of the 
video data signals at the output of the line receivers in the lOT 
depends on the propagation delay tolerances of the interface 
circuits and cables of the respective paths (refer to section 7.2 
for an analysis of the timing tolerances). The absolute delay of 
video data relative to line sync or byte clock at the lOT depends 
on the cable lengths employed in the interface connection, and 
is not critical. The procedures for image registration in the fast 
scan direction will automatically compensate for this delay. The 
number of bytes of page video per scan line will be equal to 
integer N/8, where N is the number of pixels per scan line of the 
current image. The PSP must align the page video pixels within 
the standard image frame, in both the slow and fast scan 
directions, according to the paper registration mode of the lOT 
and the current paper size. The accuracy of this alignment is a 
PSP performance parameter, not specified in this standard. 

The PSP must guarantee that video data on all lines corresponds 
to the background level during the registration and overscan byte 
clocks, and must also place all video data lines at the background 
level whenever byte clocks are not present. 

4.2.2 Serial mode (refer to figure 4-4) 


Line sync This is the primary timing reference for this group of signals. 

Line sync is a binary signal whose true state delineates the fast 
scan dimension of the standard image frame to the PSP. Thus, 
the rising edge (positive transition) of line sync indicates to the 
PSP that it must prepare to deliver the first pixel of the standard 
image frame. Positive transitions are from the 0 logic level to the 
1 logic level, as observed on the positive rail of the balanced 
interface connection (the negative rail will have the logical 
inverse transitions). Line sync is considered to be true when it is 
in the logic 1 state, as defined above. The actual duration of line 
sync true must include all of the pixel clocks which constitute the 
standard image frame, plus a minimum of 120 nanoseconds 
preceding the first transition of pixel clock (refer to the 
following section). Line sync may recur regularly or irregularly. 
The dead-time interval must be a minimum of 300 nanoseconds 
so as to provide a margin at the lOT between the end of return 
pixel clock and the beginning of pixel clock for the next scan 
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line. The quiescent state of line sync is the 0 logic level on the 
positive rail of the balanced interface circuit. 

Pixel clock This is a long burst of square waves whose positive transitions are 
used to serially clock the video data out of the PSP. The clock 
period, Tpc, must be specified by the lOT and must not be less 
than 40 nanoseconds. The duty cycle of pixel clock is nominally 
50 percent. For lOTs which reclock video data, the duty cycle 
tolerance is ±5 percent. This tolerance requirement is applicable 
at the input to the line driver in the lOT. Rising edges (positive 
transitions) are from the 0 logic level to the 1 logic level, as 
observed on the positive rail of the balanced interface 
connection. The delay between the positive transition of line 
sync and the first positive transition of pixel clock must not be 
less than 120 nanoseconds at the input to the line driver at the 
lOT interface, so as to guarantee at least 100 nanoseconds delay 
at the output of the line receiver at the PSP interface. The 
number of cycles of pixel clock which constitute a scan line of 
the standard image frame is equal to the number of pixels of 
video data which represent the largest size paper that the lOT 
will accommodate, plus the lOT's paper registration tolerance, 
plus an additional 192 to 384 pixel clocks (24 to 48 byte clocks 
equivalent) for PSP image registration tolerance. The PSP may be 
designed to divide the extra 192 to 384 pixel clocks between the 
beginning and end of scan, as needed. This division is to be 
fixed for any given PSP design and not alterable from line to line 
or from page to page. If line sync dead-time is greater than 300 
nanoseconds, an lOT may continue pixel clocks into the dead¬ 
time interval of line sync, but pixel clock cycles must terminate 
at least 300 nanoseconds before the next rising edge of line 
sync. Fractional pixel clocks are not allowed. The true state 
must always be a full half cycle. The quiescent state of pixel 
clock is logic level 0 on the positive rail of the balanced interface 
circuit. 

Return pixel clock This is a binary' signal derived from pixel clock at the PSP. At 
the input to the interface line drivers in the PSP, it must be 
phased so that the positive transitions are centered in the video 
data pixel interval with a tolerance of ±5 percent. This will 
guarantee that video data can be reliably reclocked at the output 
of the line receiver in the lOF. Positive transitions are from the 0 
logic level to the 1 logic level, as observed on the positive rail of 
the balanced interface connection. Return pixel clock must 
have essentially the same epoch as pixel clock, and exactly the 
same number of cycles. 

Video data This is a binary signal with polarity convention as follows: logic 0 
level on the positive rail (logic 1 level on the negative rail) of the 
balanced interface corresponds to image background level. The 
nominal time period of a pixel of video data is determined by the 
period of pixel clock as received at the PSP. At the input to the 
line drivers at the PSP interface, video data must be phased 
relative to return pixel clock, as described previously. The 
timing relationship between return pixel clock and video data 
at the output of the line receivers in the lOT depends on the 
propagation delay tolerances of the interface circuits and cables 
of the respective paths (refer to section 7.2 for an analysis of the 
timing tolerances). The absolute delay of video data relative to 
line sync or pixel clock at the lOT depends on the cable 
lengths employed in the interface connection and is not critical. 
The procedures for image registration in the fast scan direction 
will automatically compensate for this delay. The number of 
page video pixels per scan line will be equal to the number of 
pixels per scan line of the current image. The PSP must align the 
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page video pixels within the standard image frame, in both the 
slow and fast scan directions, according to the paper registration 
mode of the lOT and the current paper size. The accuracy of 
this alignment is a PSP performance parameter, not specified in 
this standard. 

The PSP must guarantee that video data corresponds to the 
background level during the registration and overscan pixel 
clocks, and must also place the video data line at the background 
level whenever pixel clocks are not present. 

When video data is not reclocked at the lOT, the jitter of the 
data transitions caused by the interface transmission will appear 
as corresponding spatial displacements of the pixel edges on the 
output paper (refer to chapter 7). For the worst case conditions 
allowed under this standard, i.e., 25 Megabits per second over 
50 feet of cable, the jitter will be well under 5 percent. 
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Figure 4-1. Slow scan timing relationships 
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Figure 4-3. Fast scan timing relationships^ parallel mode 
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Figure 4-4. Fast scan timing relationships^ serial mode 
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Command/status 

communications 


5.1 Introduction 


This standard specifies hardware and software configurations, 
formats, and protocols, which constitute definitive parts of the 
physical layer, the data link layer, and the client layer of a 
layered architecture (refer to figure 5-1) for communicating 
Command and Status messages between PSPs and lOTs. The 
physical layer is responsible for the actual transmission and 
reception of signals in either direction, and delivery of the 
assembled messages to the associated processors. It also detects 
and reports certain exception conditions which can occur during 
transmission. The data link layer manages the message traffic 
and many of the exception conditions. The client layer 
constitutes the substantive logical aspects of the communication. 

The interface between the client layer and the data link layer is 
via software. The interface between the data link layer and the 
physical layer is both a software and a hardware interface. It may 
be partially within a commercially available protocol controller. 
Such components can provide parts of both the data link layer 
and physical layer functions. 

The command channel is also the means for down-loading blocks 
of non-image information from the PSP to the lOT. The status 
channel is the means for up-loading blocks of non-image 
information from the lOT to the PSP. 


5.2 Physical layer 


The following is a functional description of the physical layer 
implemented with a controller (refer to section 5.5) and 
interconnect hardware, including cables, cable drivers, and cable 
receivers. The nomenclature convention for the signals on the 
Command and Status channels is the same as for the Imaging 
Interface signals (refer to chapter 4). 


5.2.1 Topology 


The Command and Status communication interfaces shall 
constitute a duplex data link operating in the serial, synchronous 
transmission mode. Physically, the Command and Status data 
shall be carried (in opposite directions) on separate, serial, 
simplex, balanced interface circuits. Each transmitting function 
must have its own stable frequency source. Each receiving 
function must recover bit timing from the received data stream In 
order to reclock the received data. The channel characteristics 
and physical interfaces shall be identical for the Command 
function and the Status function, except for the direction of 
transmission and the location of the transmitting and receiving 
circuitry. The topology must be point-to-point, at the physical 
layer, i.e., only one PSP and one lOT interconnected. This 
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restriction derives from the particular data link protocol adopted 
for this interface (refer to section 5.3). 

Figure 5-1. Layered architecture, 

Command/Status communications 
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5 . 2.2 Bit stream encodings ZBI^ NRZI 


The data within a frame, i.e., between flags (refer to section 
5.3.3-a), shall undergo zero-bit-insertion (ZBl). In this encoding 
procedure, a binary 0 must be inserted by the transmitter after 
any succession of five contiguous 1s within a frame. ZBl 
prevents the occurrence of the flag pattern (01111110) anywhere 
within a frame. After the receiver recognizes a beginning flag, it 
removes any 0 which follows five contiguous Is. inserted and 
removed Os are not included in the frame check sequence 
computation (a 1 that follows five Is is not removed). 


XEROX 
Private 
▼AV Data 


5-2 


HIGH-END lOT INTERFACE 2.2 









COMMAND/STATUS COMMUNICATIONS 


5.2.3 Bit rate^ 


The bit rate shall be 9.6, 19.2, or 57.6 Kilobits per second, ±0.01 
percent. Command and Status channels must both use the same 
data rate, i.e., a transmitting function must always use the same 
data rate as its co-located receiving function. PSPs must 
implement all three data rates, and they must be programmable. 
lOTs may implement any or all of these data rates, and they may 
be programmable. The PSP is responsible for determining the 
data rate of the lOT from the lOPs transmissions, and must 
program its data rate to match. 


5.3 Data link layer 


5.3.1 Introduction 


The data link layer consists of the PSP (or lOT) operating system's 
communications, timer, and interrupt handling code, in 
conjunction with data link functions performed by a controller. 
Together these facilities implement a subset of the HDLC (High- 
level Data Link Control) protocol, which is described in the 
following international standards: 

ISO 3309, Data Communication-High-level Data Link Control 
Procedures—Frame Structure. [Ref. 1] 

ISO 4335, Data Communication—High-level Data Link Control 
Procedures—Elements of Procedures. [Ref. 2] 

ISO 6159, Data Communication—HDLC Unbalanced Class of 
Procedures. [Ref. 3], 

These standards are to be considered a part of this generic 
specification, except as modified or restricted herein. The 
particular implementation prescribed in this generic specification 
utilizes the Unbalanced Class of procedures with the 
Asynchronous Response Mode and, with the selected optional 
functions, is designated [Ref, 3] Class UAC, 1, 2, 4, 5. The 
numbered options are identified later. Under this 
implementation, the PSP has the primary responsibility for 
controlling the data link. However, it provides for unsolicited 
frame transmission from both lOT and PSP in a two-way 
simultaneous (duplex) mode. The following is a discription of 
pertinent aspects of HDLC as it is to be applied at this Interface. 


^ The term baud rate is equivalent since the transmission format is binary. 
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5.3,2 Station types 


Two types of stations are defined for the unbalanced classes of 
procedures: a primary station, which sends orders and receives 
responses, and is responsible for link level error recovery; and 
secondary stations, which receive orders^, send responses, and 
may initiate link level error recovery. The PSP is designated the 
primary station, and the lOT is designated the secondary station. 


5.3.3 Frame structure 


All transmissions are organized into frames. The frame format 
enables the receiver to determine where transmission starts and 
stops, the identity of the lOT receiving an order or sending a 
response, what actions are to be performed with the 
transmission, specific information for the receiving station, and 
data that is used to check that the frame was received without 
error. Each frame conforms to the format shown In figure 5.2. A 
frame consists of six fields in the following order: Beginning Flag 
sequence, Address(A), Control(C), Information(l), Frame Check 
Sequence(FCS), Ending Flag sequence. The Beginning and 
Ending Flag sequences are identical single-byte fixed patterns; the 
A and C fields are also one byte. The FCS field is two bytes. 
The Information field must consist of multiple bytes, or zero 
bytes. The latter case, i.e.. Information field absent, forms a 
special case In which the Control field carries supervisory 
sequences to be interpreted at the Data Link level. 

a) Flag sequence: 

All frames shall start and end with the Flag sequence. Both 
receiving stations shall continuously hunt for this sequence. 
Thus, the flag is used for frame synchronization. The beginning 
flag serves as a reference for the position of the A and C fields, 
and initiates error checking. The ending flag terminates error 
checking. Both beginning and ending flags have the binary 
configuration 01111110. The ending flag for one frame may 
serve as the beginning flag for the next frame. Also, there may 
be multiple flags repeated between frames to maintain the active 
state. Zero bit insertion (refer to section 5.2.2) prevents the flag 
pattern from occurring anywhere else in the frame. 

b) Address field: 

In order frames, the address shall identify the lOT for which the 
order is intended. In response frames, the address shall identify 
the lOT from which the response originated. The default lOT 
address is 0000 0001 (binary). Any other address assigned to an 
lOT must be known to the PSP a priori. 

c) Control field: 

The Control field may contain an order or a reponse, and/or 
frame sequence numbers, to be processed at the data link level. 
The Control Field can be in one of three formats (refer to figure 
5-2): unnumbered, supervisory, or information transfer format. 
The Control Field formats are further defined in sections 5.3.5, 
5.3.6, and 5.3.8. 


2 In the references, these are called commands. In this generic specification, the term command 
is reserved for Client Layer messages originated by the PSP (refer to chapter 6). 
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Unnumbered format: 

Unnumbered format frames are used for such functions as: 
initializing an lOT; controlling the response mode of an lOT; 
reporting certain procedural errors; and transferring data when 
the data is not to be checked as to its location in a sequence of 
frames. 

Figure 5-2, Command/Status frame structure 
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Supervisory format: 

Frames with Control Field in the supervisory format are used 
to acknowledge reception of (or to reject) preceding frames 
carrying information. They may also be used to convey ready 
or busy conditions, and to report frame numbering errors (a 
numbered frame received out of proper sequence). 

Information transfer format: 

Frames with Control Field in the information transfer format 
contain an information field which carries the PSP Command 
messages or the lOT Status messages (or carries blocks of 
data to or from the lOT). This control field, in addition to 
indicating the frame format, contains send and receive counts 
(Ns and Nr, respectively), which are used to insure that these 
frames are received in their proper order (Ns) and to confirm 
accepted information frames (Nr). 

d) Information field: 

The Information Field may carry a Client Layer Command 
message from the PSP, a Client Layer Status message from the 
lOT, or a block of data to or from the lOT. These messages or 
data blocks may be any sequence of bits whose length Is an 
integral number of eight-bit bytes, not to exceed 124 bytes, i.e., 
the total Data Link frame, excluding flags, must not exceed 128 
bytes. The actual Command/Status messages which are 
transmitted in the l-fields are defined in chapter 6. 

e) Transparency: 

The contents of the frame between the two flag sequences, 
consisting of the Address, Control, Information, and FCS Fields, 
shall be transparent to the flag detectors by virtue of the zero- 
bit-insertion coding described in section 5.2.2. 

f) Frame check sequence field: 

This field shall contain a 16-bit cyclic redundancy check (CRC) 
sequence that is the result of a computation on the contents of 
the A, C, and I fields at the transmitter. The receiver shall 
perform a similar computation and check the results against the 
known expected result. If an error is found, the frame shall not 
be accepted. (Refer to Ref. 1, section 3.6, and Annex A, for a 
full description of the CRC and discussion of implementation.) 

g) Order of bit and byte transmission: 

Addresses, orders, responses, and sequence numbers shall be 
transmitted least significant bit (Isb) first (for example, the first bit 
of the sequence number that is transmitted shall have the weight 
2^). The FCS shall be transmitted to the line commencing with 
the coefficient of the highest term. 

The Most Significant Byte (MSB) of a Command or Status 
message is transmitted first in the Information Field. The least 
significant bit (Isb) of a Command or Status byte is transmitted 
first in the Information Field. For blocks of data, the first byte is 
taken from, or placed in, memory at the start address, and so on. 
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h) Inter-frame time fill: 

Inter-frame time fill shall be accomplished by transmitting 
contiguous flags. 

i) Invalid frame: 

An invalid frame is defined as one that is not properly bounded 
by two flags, or one which is too short (for example, shorter than 
32 bits between flags). Invalid frames shall be ignored. Thus, a 
frame which ends with an all bit sequence equal to or greater 
than seven bits in duration shall be ignored. 


5.3.4 lOT operational modes 


Note: Under HDLC, operational modes are defined only with 
respect to the secondary station. 

The lOT shall operate in either the Asynchronous Response 
Mode (ARM), the Asynchronous Disconnected Mode (ADM), or 
the Initialization Mode (IM). 

ARM is a secondary station mode in which the lOT may initate 
transmission without receiving explicit permission from the PSP. 
The transmission may be used for information field transfer 
and/or tor supervisory information (for example, to indicate the 
number of the next expected information frame, transition from a 
ready to a busy condition or vice versa, occurrence of an 
exception condition). 

ADM is a secondary station mode in which the lOT is logically 
disconnected from the data link and is, therefore, not in 
operational status. (The lOT should, however, maintain the 
active channel state with the prescribed interframe time fill—refer 
to section 5.3.7). In this mode, the lOT has restricted 
asynchronous mode response capability. The lOT may initiate a 
response transmission at any time, but the transmission shall be 
limited to a request for logical connection to the PSP (DM), or a 
request for initialization (RIM) if the lOT determines that it is 
unable to function. (Refer to section 5.3.8 for definition of 
orders/responses.) In ADM, the lOT, ir capable, shall act only on 
mode setting orders and XID. Other valid orders shall cause the 
lOT in ADM to send a disconnect mode response (DM), or, if 
unable to function, a request for initialization (RIM). 

IM is an lOT mode invoked by a set initialization mode (SIM) 
order initiated by the PSP or sent by the PSP as the result of a 
request initialization mode (RIM) from the lOT. The lOT shall 
enter IM upon sending a UA in response to SIM, and shall then 
initialize its data link layer according to its own internal 
procedures. IM is a transient mode; the lOT automatically 
progresses to ADM when initialization is complete. The lOT 
power-on sequence must also cause the lOT to enter IM. No 
communication is allowed between the lOT and the PSP in IM. 
Note that IM as defined herein is not per HDLC. 

An lOT data link state diagram is shown in figure 5-5. 


5,3.5 Control Field formats 


There are three Control Field formats, defined as follows, to 
perform numbered information transfer, numbered supervisory 
functions, and unnumbered control functions and information 
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transfer. The generic formats are shown in the expanded portion 
of figure 5-2. 

a) Information transfer format—I: 

The 1 format is used to perform an information transfer. 
(Information may also be transferred in the unnumbered format, 
refer to (c), this section.) Each I frame has an N(S) sequence 
number and an N(R) sequence number. 

b) Supervisory format—S: 

The S format is used to perform link supervisory control functions 
such as acknowledge I frames, request retransmission of 1 frames, 
and to request a temporary suspension of transmission of I 
frames. 

c) Unnumbered format—U: 

The U format is used to send unnumbered information (Ul) 
frames and to provide additional link control functions. This 
format contains no sequence numbers and, consequently, 5 
"'modifier"' bit positions are available which allow definition of up 
to 32 additional order functions and 32 additional response 
functions. A total of 11 modifier codes are used to define 3 
orders, 5 responses, and 3 with dual usage as orders or 
responses (refer to section 5.3.8). 


5.3.6 Control Field parameters 


a) Modulus: 

The modulus shall be 8. Each I frame is sequentially numbered 
and may have the value 0 through 7. The sequence numbers 
cycle, modulo 8, through the entire range. 

The maximum number of sequentially numbered I frames that the 
PSP or lOT may have outstanding (i.e., unacknowledged) at any 
given time is one (1). This restriction greatly simplifies the 
maintenance of information integrity and error recovery. It also 
means that a transmit buffer need hold only one frame at a time 
awaiting acknowledgement. 

b) Frame variables and sequence numbers: 

The PSP and lOT each maintain an independent send sequence 
number N(S) and receive sequence number N(R) on the I frames 
that they send and receive. Thus, the PSP maintains independent 
N(S) and N(R) counts for I frames sent to and received from the 
lOT. And, likewise, the lOT maintains independent N(S) and 
N(R) counts for I frames sent to and received from the PSP. This 
HDLC sequence numbering facilitates an unambiguous 
retransmission strategy and precludes any confusion during 2-way 
simultaneous frame transmission. 

c) Send state variable V(S): 

The send state variable denotes the sequence number of the 
next in sequence 1 frame to be transmitted. The send state 
variable can take on the value 0 through 7. The value of the 
send state variable is incremented by one with each successive I 
frame transmission, but cannot exceed N(R) of the last received 
frame by an increment (calculated modulo 8) of more than 1, 
because the number of outstanding frames is limited to one. 
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d) Send sequence number N(S): 

Only I frames contain N(S), the send sequence number of 
transmitted frames. Prior to transmission of an in-sequence 1 
frame, the value of N(S) is updated to equal the value of V(S). 
Note that with this relationship between V(S) and N(S), and the 
limit of one outstanding frame, N(S) of a transmitted frame 
cannot exceed N(R) of the last received frame. 

e) Receive state variable V(R): 

The receive state variable denotes the sequence number of the 
next in-sequence 1 frame to be received. The receive state 
variable can take on the values 0 through 7. The value of the 
receive state variable is incremented by the receipt of an error- 
free, in-sequence 1 frame whose send sequence number N(S) 
equals the receive state variable. 

f) Receive sequence number N(R): 

All 1 frames and S frames contain N(R), the expected sequence 
number of the next received I frame. Prior to transmission of an 
! or S frame, the value of N(R) is updated to equal the current 
value of V(R). N(R) indicates that the station transmitting the 
N(R) has correctly received the I frame numbered N(R)-1. 

Note: Neither N(S) nor N(R) appears in the control field of the 
unnumbered format. 

g) Poll/Final (P/F) bit: 

All Control Field formats contain a P/F bit. In frames sent from 
the PSP, the P/F bit is referred to as the P bit. In frames sent 
from the lOT, the P/F bit is referred to as the F bit. Under 
HDLC/ARM, this bit plays an important role in maintaining the 
integrity of information exchange, and in error recovery. 
However, this function is not utilized in the PSP/IOT data link, 
because the restriction to one outstanding frame, and the direct 
physical transmission paths, render this sophistication 
unnecessary. Accordingly, the P/F bit shall be set to '"0" In all 
frames at all times. 


5.3.7 Data link channel states 


a) Active cFianne! state: 

A channel is In an active condition when the PSP or the lOT is 
actively transmitting a frame, a single abort sequence, or 
interframe time fill. In the active state, the right to continue 
transmission is reserved. 

Abort; aborting a frame is accomplished by transmitting at least 
seven contiguous bits (without zero insertion, section 5.2.2). 
Receipt of seven contiguous "1" bits is to be Interpreted as an 
abort, and the receiving station shall ignore the frame. (Note 
that a sequence of 15 or more 'H" bits will be interpreted as an 
idle condition—refer to (b). 

Interframe time fill; Interframe time fill is accomplished by 
transmitting continuous flags between frames. There is ho 
provision for time fill within a frame. 

b) Idle channel state: 

Under HDLC, a channel is defined to be in an idle condition 
when a continuous transmission of at least 15 bits is 

detected. The idle state is not to be intentionally invoked by the 
PSP or the lOT. If the idle state sequence is received, it is to be 
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interpreted as a fault condition, which must be resolved at a 
higher level. 

c) Transmission mode: 

The physical layer provides a duplex transmission facility (section 
5.2.1), and the data link must support two-way-simultaneous 
transmission of frames. Actual transmissions may occur as two¬ 
way-simultaneous (duplex) or two-way-alternate (half-duplex) 
frame sequences. 


5*3.8 Order/response definitions 

a) Summary: 

The subset of HDLC order and response frames to be used for 
the interface data link is tabulated below, and the Control Field 
bit formats are shown in figure 5-3. Note that some are orders 
only, some are responses only, and some serve as both orders 
and responses. 


Name 

Acronym 

Order 

Response 

/ (Information) format 

Information 

1 

X 

X 

S (Supervisory) format 

Receive Ready 

RR 

X 

X 

Receive Not Ready 

RNR 

X 

X 

Reject 

RE] 

X 

X 

U (Unnumbered) format 

Unnumbered Information 

Ul 

X 

X 

Request Initialization Mode 

RIM 


X 

Set Initialization Mode 

SIM 

X 


Set Asynchronous Response Mode 

SARM 

X 


Disconnect Mode 

DM 


X 

Disconnect 

DISC 

X 


Unnumbered Acknowledge 

UA 


X 

Frame Reject 

FRMR 


X 

Request Disconnect 

RD 


X 

Exchange Identification 

XID 

X 

X 

Test 

TEST 

X 

X 


XEROX 

Private 

Data 


5-10 


HIGH-END lOT INTERFACE 2.2 










COMMAND/STATUS COMMUNICATIONS 


Figure 5-3. Control Field bit formats 
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(b1 and b5 are the lower order bits of N(S) and N(R). respectively.) 


b) I (Information) format: 

The !, Information, order/response is used by both the PSP and 
the lOT to transfer across the interface data link sequentially 
numbered frames containing an information field. The 
information field may be of any length up to the maximum of 
124 bytes. The variable content of the I frame Control Field 
consists of two sequence numbers, N(S) and N(R) (refer to 
section 5.3.6 for a discussion of the sequence numbers). 

Each correctly received l-frame shall be acknowledged by the 
receiving station at the earliest opportunity. Acknowledgement 
shall be via the value of Nr (incremented from the previous 
response) in a return l-frame or in an RR frame. Incorrectly 
received l-frames shall be handled as described in section 5.3.9. 

c) S (Supervisory) format: 

Supervisory order/responses are used by both the PSP and the 
lOT to perform numbered supervisory functions, such as 
acknowledgement, temporary suspension of information transfer, 
or error recovery. 

Frames with the S format shall not contain an information field 
and, therefore, do not increment the sequence numbers at either 
the transmitter or receiver. 

The individual S frame formats are identified by the two S bits in 
the Control Field. The variable content of an S frame Control 
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Field consists of the receive sequence nunnber, N(R). N(R) 
indicates the sequence number of the next expected I frame to 
be received at the time of transmission, and consequently 
indicates that the 1 frame numbered N(R)-1 has been correctly 
received (refer to section 5.3.6 for discussion of the sequence 
numbers). 

RR, Receive Ready: 

The RR frame is used by the PSP or the lOT to: 

• Indicate it is ready to receive an I frame; 

• Acknowledge previously received I frame numbered N(R)- 
1 at the earliest opportunity; 

• Clear a busy condition that was initiated by the 
transmission of RNR. 

REJ, Reject: 

This is an HDLC optional function which constitutes option 2 in 
the class of procedures designation (section 5.3.1). The REJ 
frame is used by the PSP or the lOT to request retransmission of 
the I frame numbered N(R). Only one REJ exception condition 
can be established at any given time in each direction of 
transm.ission because of the limitation of one unacknowledged 
frame. Another REJ may not be effected until the first RE] 
exception condition has been cleared. The RE] exception 
condition is cleared (reset) upon receipt of an I frame with an 
N(S) equal to the N(R) of the original RE] frame. 

When used, RE] must be sent at the earliest opportunity 
following receipt of an out-of-sequence l-frame. 

RNR, Receive Not Ready: 

The RNR frame is used by the PSP or the lOT to Indicate a busy 
condition, i.e., temporary inability to accept additional incoming I 
frames. I frame numbered N(R)-1 is acknowledged. I frame N(R) 
is not acknowledged. The acceptance status of this frame will be 
Indicated in the subsequent exchange. 

Indication that the busy condition has cleared and I frames will 
now be accepted is communicated by the transmission of an RR, 
RE], SARM, UA, or an I frame. 

An lOT receiving an RNR frame when in the process of 
transmitting (i.e., two-way simultaneous) shall stop transmitting 1 
frames at the earliest possible time. 

d) U (Unnumbered) format: 

Unnumbered order/responses are used to extend the number of 
link control functions. Three of the formats are used only for 
orders, five are used only for responses, and three are used for 
both. Frames transmitted with the U format do not increment 
the sequence counts at either the transmitting or receiving 
station. 

The individual U frame formats are identified by the five M 
(modifier) bits in the Control Field. There are no variables in a U 
frame Control Field. 

Ul, Unnumbered Information: 

This is an HDLC optional function which provides the ability to 
exchange information fields without impacting the I frame 
sequence counts. It is option 4 in the class of procedures 
designation (section 5.3.1). A Ul frame does not require 
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acknowledgement. The information field of a U1 frame may be 
of any length up to the maximum of 124 bytes. 

RIM, Request Initialization Mode: 

This is an HDLC optional function which provides lOT ability to 
request initialization. Together with SIM, discussed in the 
following section, it constitutes option 5 in the class of 
procedures designation (section 5.3.1). 

Once an lOT has requested initialization from the PSP, i.e., 
established a RIM condition, additional orders subsequently 
received (other than SIM or DISC or, if capable, XID) shall be 
monitored only to detect a respond opportunity to retransmit 
RIM. No additional transmission shall be accepted or actioned 
until the condition is reset by the receipt of SIM or DISC. No 
information field is permitted with the RIM response. 

SIM, Set Initialization Mode: 

This is an HDLC optional function which provides PSP ability to 
initialize the lOT. Together with RIM, discussed previously, it 
constitutes option 5 in the class of procedures designation 
(section 5.3.1). 

The SIM order causes the lOT to enter the Initialization mode 
(section 5.3.4). No information field is permitted with the SIM 
order. Prior to acting on this order, the lOT must confirm 
acceptance of SIM by transmitting the UA response. The UA 
response takes precedence over any 1 or S format response 
pending, and must be made at the first opportunity. The lOT may 
ignore ail frames received following this order until UA has been 
sent. Upon acceptance of this order, the lOT send and receive 
variables are set to zero. 

Previously transmitted I frames that are unacknowledged when 
this order is actioned remain unacknowledged. Whether the 
station retransmits unacknowledged outstanding 1 frames or not 
must be decided at a higher level. 

SARM, Set Asynchronous Response Mode: 

The SARM order is used to place the lOT in the asynchronous 
response mode (ARM). No information field is permitted with 
the SARM order. The lOT confirms acceptance of SARM by 
transmission at the first respond opportunity of a UA response. 
The UA response takes precedence over any 1 or S format 
response pending, and must be made at the first opportunity. 
The lOT may ignore all frames received following this order until 
UA has been sent. Upon acceptance of this order, the lOT send 
and receive variables are set to zero. 

Previously transmitted 1 frames that are unacknowledged when 
this order is actioned remain unacknowledged. Whether the 
station retransmits unacknowledged outstanding I frames or not 
must be decided at a higher level. 

DM, Disconnect Mode: 

The DM response Is used by the lOT to report that It is logically 
disconnected from the link, and is by definition in ADM. An lOT 
in ADM may send a DM response at any respond opportunity. 
The DM response is sent by the lOT in ADM, to inform the PSP 
that it is still in ADM and cannot action a set mode order. No 
information field is permitted with the DM response. 

An lOT in ADM shall monitor received orders to detect a 
respond opportunity in order to (re)transmit DM (or RIM, XID, or 
RD as appropriate), i.e., no orders (other than XID) are accepted 
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until the disconnected mode is terminated by the receipt of 
SARM or SIM. 

D/SC Disconnect: 

The DISC order Is used to inform the lOT that the PSP is 
suspending operation and that the lOT should enter ADM. No 
information field is permitted with the DISC order. Prior to 
acting on this order, the lOT must confirm acceptance of DISC 
by transmitting the UA response. The UA response takes 
precedence over any I or S format response pending, and must 
be made at the first opportunity. The lOT may ignore all frames 
received following this order until UA has been sent. 

Previously transmitted I frames that are unacknowledged when 
this order is actioned remain unacknowledged. Whether the 
station retransmits unacknowledged outstanding I frames or not 
must be decided at a higher level. 

UA, Unnumbered Acknowledge 

The UA response is used by the lOT to acknowledge the receipt 
and acceptance of the U format orders defined above. Received 
U format orders are not actioned until the UA response is 
transmitted. No information field is permitted with the UA 
response. 

FRMR, Frame Reject: 

Note: The CMDR nomenclature used for this function in Ref. 2 
is believed to be obsolete. 

The FRMR response is used by an lOT In ARM to report to the 
PSP that certain exception conditions have occurred upon receipt 
of a frame without FCS error. The lOT must respond at the first 
opportunity. A three-byte information field which Identifies the 
exception condition(s) is returned with this response. Included 
in the information field are the lOT's current N(S) and N(R), and 
the Control Field of the rejected order (as received). The format 
of the information field Is shown in figure 5-4. The exception 
conditions and the method of reporting them are as follows: 

— Bit "w" is set to "V to indicate that the Control Field 
received and returned in the first byte of the information field 
is invalid or not implemented. 

— Bit "x" is set to to indicate that the Control Field received 
and returned in the first byte of the information field is 
considered invalid because the frame contained an 
information field which is not permitted with the received 
Control Field format. Bit "w" must be set to if bit "'x" is 
set to "1". 

— Bit "y" is set to "1" to indicate that the information field 
received exceeded the maximum length allowed (124 bytes) 
or the capacity of the lOT’s receiving buffer. This applies to 
Ul and XID frames as well as to I frames. 

— Bit "z" is set to "1" to indicate that the Control Field received 
and returned in bits 1 through 8 (first byte of the information 
field) contained an invalid N(R). 

An invalid N(R) is defined as one which points to an I frame 
which has previously been transmitted and acknowledged, or to 
an I frame which has not been transmitted and is not the next 
sequential I frame pending transmission. 
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Figure 5-4. Information field format of the FRMR response, 
as transmitted 
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The w, X, y, and z bits in the information field of FRMR may all be 
set equal to zero, indicating an unspecified rejection of the order 
for one or more of the conditions cited above. 

RD, Request Disconnect 

This is an HDLC optional function which provides the lOT ability 
to request logical disconnection, i.e., transition to ADM. It is 
option 1B. Together with XID, discussed in the following 
section, it constitutes option 1 in the class of procedures 
designation (section 5.3.1). No information field is permitted 
with the RD response. 

An lOT which has sent an RD response and receives an order 
frame (or frames), other than DISC shall accept the order frame 
(or frames) if it is able to do so. If the lOT accepts the non-DISC 
order frame (or frames), it shall follow the normal procedures to 
respond to the PSP. lOT acceptance of a frame other than DISC 
after sending an RD response shall cancel the RD response. 

If the lOT still wishes to be placed in ADM, it shall re-issue the 
RD response. If the lOT cannot accept the non-DISC frames due 
to internal problems, it may respond with RD again. 

XID, Exchange Identification: 

This is HDLC option 1A. Together with RD, it constitutes option 
1 in the class of procedures designation (section 5.3.1). 

The XID order is used by the PSP to solicit identification of the 
lOT. An information field may be included in the order frame to 
convey identification and certain characteristics of the PSP. 

The XID response is required from the lOT. An information field 
is included in the response frame to convey identification and 
certain characteristics of the lOT. The lOT must respond in any 
mode, unless a UA response to a mode setting order is pending, 
or a FRMR condition exists. 

TEST, Test: 

The TEST order is used by the PSP to solicit a TEST response from 
the lOT. The lOT must respond in any mode. If an information 
field is included in the order, it is returned in the response. If 
the lOT has insufficient buffering available for the information 
field, a TEST response with no information field is returned. 

Note: HDLC does not prescribe a TEST command. This 

command is taken from SDLC, Ref. 4. 
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5.3.9 Exception reporting and recovery 


This paragraph describes the error recovery procedures which are 
available to effect recovery following the detection/occurrence of 
an exception condition at the data link level. Exception 
conditions described are those situations which may occur as the 
result of transmission errors, station malfunction, or operational 
situations. Note that until the sending station receives 
acknowledgement of a transmitted frame, it must retain the 
original frame in memory, in case the need for retransmission 
should arise. 

a) Busy: 

The busy condition results when a station is temporarily unable 
to receive or continue to receive 1 frames due to internal 
constraints, for example, buffering limitations. In this case, an 
RNR frame is transmitted from the busy station. Traffic pending 
transmission may be transmitted from the busy station prior to or 
following the RNR. Indication that the busy condition has 
cleared and I frames will now be accepted is communicated by 
the transmission of an RR, REJ, SARM, UA, or an 1 frame. 

b) N(S) Sequence error: 

An N(S) sequence exception condition occurs in the receiver 
when an 1 frame received error free (no ECS error) contains an 
N(S) that is not equal to the receive state variable V(R) at the 
receiver. The receiver does not acknowledge (increment its 
receive state variable) the frame causing the sequence error, or 
any 1 frames which may follow, until an 1 frame with the correct 
N(S) is received. The information field of all 1 frames received 
whose N(S) does not equal the receive state variable V(R) will be 
discarded. 

A PSP or lOT which receives an I frame having a sequence error, 
but FCS-error free, shall accept the control information contained 
in the N(R) field in order to receive acknowledgement of a 
previously transmitted 1 frame. Therefore, the retransmitted I 
frame may contain an N(R) field that is updated and, therefore, 
different from that contained in the originally transmitted I frame. 

The station receiving an l-frame with N(S) not equal to its V(R) 
shall respond with an l-frame, or REJ, with N(R) still equal to its 
(unincremented) V(R). The sending station must then transmit 
(or retransmit) the frame with the required N(S), i.e., matching 
the N(R) which caused the exception condition. If there has 
been a procedural error at either end so that N(S) remains 
unequal to N(R) in the retransmission and the exception 
condition is not cleared, the problem must be resolved at a 
higher level. Resolution may involve sending SARM to reset the 
IOT*s sequence variables to zero. 

c) FCS error: 

Any frame received with an FCS error is not accepted by the 
receiver. The frame is discarded, and no action is taken as the 
result of that frame. As a result, the sending station will 
experience an acknowledgement time-out and will commence 
retransmission as described in e). 

d) Order Rejection (FRMR): 

An order rejection condition is established by the lOT upon the 
receipt of an error-free order frame which contains an invalid 
Control Field, an invalid frame format, an invalid N(R), or an 
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information field which exceeds the maximum length allowed 
(124 bytes), or exceeds the capacity of the 10T*s receiving buffer. 

At the PSP, this exception condition must be resolved at a higher 
level. At the lOT, this exception condition is reported via a 
FRMR response for appropriate action by the PSP. Once an lOT 
has established a FRMR exception, no additional I frames are 
accepted, except for examination of the N(R) field, until the 
condition is reset by the PSP. The FRMR condition may be reset 
by reception of a mode setting order or a DISC order. 

e) Time-out and retransmission strategy: 

In order to detect a no-reply or a lost-reply condition, the PSP 
and lOT shall each employ a time-out and retransmission strategy 
as follows: 

i) The sending station of the PSP and the lOT data link layers 
shall each start an acknowledge time-out at the end of 
each outgoing frame which requires acknowledgement (via 
either receive-sequence-number or via UA). The duration 
of the acknowledge time-out shall be specific to the 
design of the lOT or PSP containing the receiving station 
and should be based on the frame processing time of the 
particular receiving station. It shall be as short as possible, 
but long enough to guarantee that correctly received 
frames are acknowledged, and, in any case, must be 
longer than 5 milliseconds. Note that the duration of the 
acknowledge time-out may be different for the two 
directions of transmission on a given duplex data link. The 
receiving stations' acknowledgement time requirements 
must be conveyed as the parameter DataLInkAckTime in 
the Client Layer messages, PspConfiguration, and 
lotConfiguration (refer to sections 6.3.2 and 6.3.3). 

ii) Acknowledgement must be sent by the receiving station 
at the first opportunity, and the sending station's 
acknowledgement time-out must be stopped and reset 
upon reception of the acknowledgement. 

iii) If an acknowledge time-out reaches completion, the 
sending station may retransmit the unacknowledged frame 
in a continuing attempt to obtain acknowledgement. The 
number of retransmissions and the interval over which the 
retransmissions occur shall be determined by the sending 
station, according to its own operational limitations, and 
may, for example, depend on the length of the frame 
and/or the particular machine state. The retransmission 
strategy of the sending station need not be known to the 
receiving station a priori. 

iv) lf a sending station terminates its retransmission strategy 
without success, the situation must be reported to a 
higher level for resolution. 

Note: It is possible for an interface incompatibility to exist in 
regard to acknowledge time, e.g., the receiving function of a PSP 
might have a guaranteed acknowledgement time too long to 
support the real-time operation of an lOT with which It is 
proposed to interface. In that case, the acknowledgement time 
is to be considered part of the performance criteria which 
establishes the peer relationship in the compatibility requirement 
stated in the first paragraph of chapter 2, "Introduction." 
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5.4 Procedures (refer to figures 5-5, 5-6, and 5-7) 


5.4.1 Initializing 


With both units in the power-off state, the first action is to 
manually turn on the PSP AC power. The DC power is 
sequenced on automatically, and the power-on reset causes the 
PSP firmware and software to execute its initialization 
procedures. This will cause the lOT AC power to be turned on 
automatically via the power control interface signal. 
(Alternatively, the lOT power-on may be initiated manually at the 
PSP, or it may be accomplished manually at the lOT.) The 
power-on condition of the lOT will be verified to the PSP by the 
power monitor interface signal, if implemented (refer to section 
3.2.5). The lOT DC power is sequenced on automatically, and 
the power-on reset causes the lOT firmware and software to 
execute its initialization procedures. The initialization procedures 
of the PSP and lOT also initialize the physical layers and the data 
link layers of their respective Command/Status interfaces. This 
means that the hardware and software is initialized as required to 
perform the signalling and protocol functions prescribed in 
sections 5.2 and 5.3. When initialization is complete, the lOT 
data link shall automatically advance to the asynchronous 
disconnect mode (ADM), and each direction of the interface 
channel shall be In the active state with each transmitter 
transmitting contiguous flags. And each receiver, as a result of 
first placing its bit timing recovery circuits in the search mode, 
should be locked on to the incoming signal and be looking for 
valid frames. Note that the lOT will transmit at its fixed or set 
data rate, and the PSP must detect this rate and adjust its send 
and receive data rates to match. 

The PSP and lOT may exchange certain unnumbered frames while 
the lOT is in ADM, for example, RIM and/or SIM, and XID. 


5.4.2 Establishing the data link 


when ready to establish the data link, the PSP shall transmit 
SARM. The lOT, upon receiving SARM correctly, shall send UA at 
its first opportunity, set its send and receive variables to zero, 
and assume the asynchronous response mode (ARM). If the UA 
response is correctly received, the data link is established and the 
PSP shall set its send and receive variables to zero. 

If the UA response is not received correctly by the PSP, or is not 
sent because SARM was not received correctly by the lOT, the 
PSP may enter the retransmission mode when its acknowledge 
time-out is completed. If the recovery procedure is not 
successful, the problem must be resolved at a higher level. 


5.4.3 Exchange of information 


Information frames, supervisory frames, and unnumbered frames 
are exchanged as prescribed in section 5.3, and illustrated in 
figure 5-7. Further examples of typical exchanges, with and 
without errors, are given In Ref. 2, Annex C, under C.4, 
''Examples of asynchronous response mode (ARM) 2-way 
simultaneous (FDX) transmission" (refer to chapter 6 for 
definition of Client Layer messages indicated informally in figure 
5-7). 
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5.4.4 Logically disconnecting the data link 


The PSP shall send DISC. The lOT, upon receiving DISC 
correctly, shall send UA at its first opportunity and then enter the 
asynchronous disconnect mode (ADM). The lOT transmits 
contiguous flags to maintain its half of the duplex channel in the 
active state. If the UA response is correctly received by the PSP, 
the PSP shall consider that the lOT is in ADM. The PSP transmits 
contiguous flags to maintain its half of the duplex channel in the 
active state. 

If the UA response is not received correctly by the PSP, or is not 
sent because DISC v\'as not received correctly by the lOT, the 
PSP may enter the retransmission mode when its acknowledge 
time-out is completed. The lOT may respond with either UA or 
DM during the recovery' procedure. If the recovery procedure is 
not successful, the problem must be resolved at a higher level. 

The PSP and lOT may exchange certain unnumbered frames while 
the lOT is in ADM, for example, RIM and/or SIM, and XID. 


5.4.5 Shutting down the data link 


The interface channel remains in the active state in both 
directions until DC power to the Interface circuits Is removed by 
the automatic power-down sequence, which may be initiated 
manually or automatically. 


5.5 Implementation 


This specification does not require a particular physical 
implementation of either the physical layer or the data link layer; 
however, there are a number of commercially-available multi¬ 
protocol serial controller (MPSC) chips which perform HDLC 
functions, as well as physical layer functions. Many of the 
functions and their parameters are programmable. Typically, 
these chips supply most or all of the following: 

One or two full duplex serial data channels with TTL 
interfaces. 

Byte-wide, bi-directional data bus interface. 

Vectored interrupt for controlling transmit and receive data 
transfer, and for reporting exception conditions. 

Automatic flag generation and detection. 

Automatic address recognition. 

Automatic CRC generation and checking. 

Frame assembly, byte-parallel to byte-serial, in transmission 
mode. 

Frame disassembly, byte-serial to byte-parallel, in receive 
mode. 

Zero-bit-insertion and removal. 

NRZI encoding and decoding. 

Programmable data rates. 


HIGH-END lOT INTERFACE 2.2 


5-19 









COMMAND/STATUS COMMUNICATIONS 


Bit-clock recovery from the received data stream, including 
sync search. 

Automatic determination of received data rate. 


5.6 Client layer 


The client layer is a software entity which interfaces with the data 
link layer and allows remote processes to communicate with each 
other without knowledge of the intervening communications 
protocols. Refer to chapter 6 for a full description of the Client 
Layer Protocol. 


4 VA XEROX 
goS Private 
Data 
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Figure 5-6. Data link initialization 
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Figure 5-7. Data link communication sequence 
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See para. 6.4.5 and Fig. 6.6 for details. 
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Poll/Final bit (na) - 


Symbolic Frame Format 
{C (Ns) / (ljU) (...J ) 


Information Field, if present (Client Layer message. See Section 6) 
Receive Number (absent if not req’d) 


HIGH-END lOT INTERFACE 2.2 


5-23 







6 


Client layer protocol 


The Client layers of the PSP and lOT software will communicate 
via the set of Command and Status messages listed and defined 
below. These messages constitute the information field of the 
HDLC frame defined in chapter 5. In general, they should be 
sent in the numbered Information format. Possible exceptions 
are cited below in the application notes of the pertinent 
messages. 


6.1 Identification code assignments^ and page references 


Code 

Command 

Page 

Code 

Status 

Page 

01 

PspConfiguration 

6-5 

81 

lOTCONFIGURATION 

6-38 

02 

PspmetaReset 

6-7 

82 

IotmetaReset 

6-49 

03 

PspNextBankRequest 

6-8 

83 

IotVideoHint 

6-50 

04 

PspPrint 

6-18 

84 

IotVideoRequest 

6-52 

05 

(u/a) 


85 

(u/a) 


06 

PspReadIotMemory 

6-20 

86 

IotWriteMemoryToPsp 

6-53 

07 

PspReadIotState 

6-20 

87 

IotStateInfo 

6-54 

08 

PspReadIotO,perational1nfo 

6-21 

88 

IotOperationalInfo 

6-58 

09 

PspRequestIotDiacnostic 

6-22 

89 

IotDiagnostigResponse 

6-63 

OA 

(u/a) 


8A 

(u/a) 


OB 

PspRejectIotMessace 

6-24 

8B 

IotRejectPspCommand 

6-65 

OC 

PspSheetBankAbort 

6-27 

8C 

IotSheetDelivered 

6-68 

OD 

pspWriteiotmemory 

6-29 

8D 

IotRequestMemory 

6-70 

OE 

PspRequestIotAction 

6-30 , 

8E 

IotSwitchInfo 

6-71 

OF 

PspRequestIotStateChange 

6-35 

8F 

(u/a) 
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6.2 Summary of parameter assignments 

6.2.1 PSP to lOT Command messages 


■ Number of 

COMMAND (ID hex) Parameters 

PspConfiguration (01) 2 

Response: IotConfiguration or none 

PspMetaReset (02) 1 

Response: none 

PspNextBankRequest (03) 21 

Response: none 


PspPRINT (04) 4 

Response: IotVideoRequest 

PspReadIotMemory (06) 3 

Response: IotWriteMemoryToPsp 

PspReadIotState (07) 0 

Response: IotStateInfo 

PspReadIotOperationalInfo (08) 1 

Response: IotOperationalInfo 

PspRequestIotDiagnostic (09) 4 

Response: IotDIagnosticResponse 

PspReiectIotMessage (OB) 8 

Response: IotStateInfo, or 

IotOperationalInfo 


PspSheetBankAbort (OC) 4 

Response: IotStateInfo 

PspWriteIotMemory (OD) 4 

Response: none 

PspRequestIotAction (OE) 4 

Response: IotOperationalInfo 

PspRequestIotStateChange (OF) 1 

Response: IotStateInfo 


Total no. 

Param. . 

Bytes Parameter names (no. of bytes) 

2 Command(l), Data(1) 


1 PspMessage(l) 


27 PlateMode(l), SheetNumber(2), 
NumberOfCopies(2), 

NextBankTasl<InfoA(1), 

NextBanl<TaskInfoB(1), 

NextBankTaskInfoC(1), 

BindexerFlllLimit(1), SorterBindestination(1), 
StitchAPosition(1), StitchBPosition(1), 
FeederPermissions(1), 
DestinationPermissions(1), 
ManualFeederPermissions(l), 
ManualDestinationPermissions(l), 
PaperWldth(2), 

PaperLength(2), PaperType(l), 
FutureFinishingOptions(2), JobNumber(l). 
ContrastAction(1), ContrastData(2) 

6 PlateNumber(l), SheetNumber(2) 

CopyNumber(2), JobNumber(l) 

9 Spare(l), StartAddress(4), 

EndAddress(4) 


1 InformationType(1) 


7 Command(l), Utility(2), ParameterID(2), 

ParameterValue(2) 

10-13 Reason(1), IotStatusRejected(1), 
lotStatusParameterNumber(l), 
SheetNumber(2), CopyNumber(2), 
JobNumber(l), Spare(l) 
IotStatusParameterValue(1 - 4) 

6 AbortType(l), SheetNumber(2), 

CopyNumber(2), JobNumber(l) 

7-123 EndOfBlock(l), StartAddress(4), Length(l), 
Data(1-117) 

5 Device(l), Set(1), Action(l), Data(2) 


1 ChangeRequested(1) 


6-2 


XEROX 


HIGH-END lOT INTERFACE 2.2 










CLIENT LAYER PROTOCOL 


6.2.2 lOT to PSP Status messages 


—Total no. 
Number of Param. 


STATUS (ID hex) 

Parameters 

Bytes 

Parameter names (no. of bytes) 

IotConficuration (81) 

2 

5,10,11, 
or 17 

InformationType(l), DataField(4,9,10, or 16) 

IotMetaReset (82) 

2 

3 

iotStatus(2) ResetMode(1) 

IOTVIDEOHINT (83) 

4 

6 

PlateNumber(l), SheetNumber(2), 
CopyNumber(2), ]obNumber(1) 

IotVideoRequest (84) 

4 

6 

PlateNumber(l), SheetNumber(2), 
CopyNumber(2), ]obNumber(1) 

IotWritememorytoPsp (86) 

4 

7-123 

EndOfBlock(l), StartAddress(4), Length(l), 
Data(1-117) 

IotStateInfo (87) 

2 

2 

MachineState(l), Substates(l) 

IotOperationalInfo (88) 

2 

7 or 
2-123 

InformationType(l), DataField(6, or 1-122) 

IotDiacnosticResponse (89) 

4 

7 

Status (1), Utility(2), ParameterlD(2), 
ParameterValue(2) 

IotRejectPspCommand (8B) 

8 

10-13 

iotReason(l), PspCommandRejected(l), 
PspCommandParameterNumber(1), 
SheetNumber(2), CopyNumber (2), 
]obNumber(1), Spared), 
PspCommandParameterValue(1-4) 

IotSheetDelivered (8C) 

6 

8 

lntegrity(1), SheetNumber(2), 
CopyNumber(2), Destination(l), 

SorterBin(1), JobNumber(1) 

IotRequestMemory (8D) 

3 

9 

Spare(l), StartAddress(4), EndAddress(4) 

lOTSWITCHlNFO (8E) 

2 

2 

Switch(l), Action(l) 


6.3 Detailed description of Command and Status messages 


6.3.1 Presentation format 


The following sections define the high-level Command and Status 
messages passed between the PSP and the lOT client layers. The 
notation used is as follows: 

Special characters: 

= is defined to be 

[a..b] the interval a through b 

I or 

- a comment follows 

Uppercase: denotes a keyword constant which is fixed in 

value. 

(Example Machine ::= 1) 
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Lowercase: denotes a variable. (Example FaultState :: = 

[1..25] ) 

The Command and Status message fields are composed of both 
byte-oriented and non-byte-oriented operands. When the 
operands are represented as numerical entities, normal English 
reading custom is followed, i.e., the left most digit is the most 
significant and the right most digit is the least significant, whether 
in hexadecimal or binary notation. The messages are packed so 
that non-byte-oriented operands fall on word boundaries in order 
to facilitate byte swapping, which is inevitable when 
communicating between processors with different internal byte 
ordering schemes. 

Note that the bytes of the message fields are numbered in order 
of transmission, i.e., most significant byte first, which is the 
normal order of reading the entity when written as a number. 
The bit definitions are also numbered in order of transmission 
(within a byte), i.e., least significant bit first, which is opposite to 
the normal order of reading the entity when written as a number. 
For a typical message with byte-oriented operands only, the 
appearance within the information field of an HDLC frame, i.e., in 
order of transmission, is shown in figure 6-1. A typical message 
including a non-byte-orlented operand (16-bit number) is shown 
in figure 6-2. 

Where it is necessary to reference the parameters of the 
Command and Status messages by number, the parameters are 
considered to be numbered in order of transmission, beginning 
with number one. (Note that the parameter numbering does not 
necessarily correspond to the byte numbering.) Parameter 
numbering is not shown in the following format descriptions. 

All spare bytes and spare parameter values are reserved and can 
be assigned only through amendment to this generic 
specification. 
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6.3.2 PSP Command messages 

PspConfiguration (01) 

PARAMETERS Command (1) Data(1) 

ORIGINATOR PSP 

FUNCTION To inform the lOT of the PSP configuration. 

TRANSMISSION ORDER: 


Byte Nos. 


10 CODE 


Command 


Data 


BO B1 82 


DEFINITION: 

PspConfiguration 

IdCode 

BO 

Command Data 
B1 B2 


VerifyOutputDelivery 

ReturnOutputSheetNumber 

No 

OfLastSheet 

OfEachSheet 

VerifyDuplexDelivery 

ReturnDuplexSheetNumber 

No 

Yes 


:;= IdCode Command Data 
::= BO --byte 0 
= 01 hex 
::= B1 B2 

:: = VerifyOutputDelivery 

ReturnOutputSheetNumber 
I VerifyDuplexDelivery 
ReturnDuplexSheetNumber 
I SchedulingOffset NumOfPageSyncs 
1 DataLinkAckTime Time 
I ReturnIotconfiguration NoData 
I SpareCommands SpareData 


01 hex 

" Return the sheet number of 
delivered sheets as requested. 

No OfLastSheet OfEachSheet 

00 hex 


01 hex 


02 hex 

- Refer to “Appl. notes,” following. 

02 hex 

- Return the sheet number of each 
sheet delivered to the duplex tray, as 
requested. 

No I Yes 


00 hex 


01 hex 



I AfA XEROX 
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SchedulingOffset 


Undefined 

NumOfPageSyncs 

DataLInkAckTime 

Time 

ReturnIotConfiguration 

NoData 

SpareCommands 

SpareData 


= 03 hex - The number of Page Sync positive 
transitions between PspPrint and 
IotVideoRequest as required by the 
PSP. 

:: = 00 hex 
:: = [01 .. FF] hex 
:: = 04 hex 

:: = [00 .. FF] hex -- in milliseconds 
= 05 hex 

:: = 00 hex -- data not applicable 
= [06 .. FF] hex 
:: = [00 .. FF] hex 


RESPONSE IotConfiguration in response to ReturnIotConfiguration command parameter, 

otherwise none 

APPLICATION NOTES Where sheet number is required, it is to be understood that copy 

number must also be included. 

DataLinkAckTime is the time which the PSP guarantees not to 
exceed when acknowledging (positively or negatively) a received 
data link frame which requires acknowledgement. This time 
becomes the acknowledgement time-out employed by the lOT 
data fink transmitting function. Refer to section 5.3.9-e. 

If ReturnOutputSheetNumber-OfEachSheet is designated in 
conjunction with an output finishing device that has an 
intermediate destination, an 8x hex series destination code will 
be returned as each sheet is delivered to the intermediate 
destination. When the set is ejected to the final destination, an 
Ox hex series final destination code will be returned with the last 
sheet number only. (Refer to lotSheetDelivered.) 
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PspMetaReset (02) 

PARAMETERS PspMessage (1) 

ORIGINATOR PSP 

FUNCTION To inform the lOT that an unrecoverable problem has been detected and instruct the 
lOT to take appropriate action. 

TRANSMISSION ORDER: 


ID CODE 


PspMessagei 


Byte Nos. 


BO 


B1 


DEFINITION: 

PspMetaReset 

IdCode 

BO 

PspMessage 

B1 

PspPowerOffNotice 

PspSoftwareReset 

Spare 


IdCode PspMessage 
BO --byte 0 
02 hex 
B1 

PspPowerOffNotice | PspSoftwareReset | Spare 

01 hex " Notice that lOT power loss will occur. 
02 hex - lOT to reset w/o softload. 

[03 .. FF] hex - Program specific. 


RESPONSE none 

APPLICATION NOTES This message may be sent in the Un-numbered information format of the 

HDLC frame to preclude the possibility of invoking the data link time-out and 
retransmission strategy during implied exception conditons. 
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PspNextBankRequest (03) 

PARAMETERS PlateMode (1) SheetNumber (2) NumberOfCopies(2) NextBankTasklnfoA (1) 
NextBankTaskinfoB (1) NextBankTaskinfoC (1) BindexerFiilLimit (1) 
SorterBinDestination (1) StitchAPosition (1) StitchBPosition (1) 

FeederPermissions (1) DestinationPermissions (1) ManualFeederPermissions (1) 
ManualDestinationPermissions (1) PaperWidth (2) PaperLength (2) PaperType (1) 
FutureFinishingOptions (2) JobNumber (1) ContrastControl (1) ContrastData (2) 

ORIGINATOR PSP 

FUNCTION To inform the lOT about a bank that will be run. The switch to the next bank will 
happen after the PSP requests the SheetNumber via PspPrint. 

TRANSMISSION ORDER: 


ID Code 

Plate 

Mode 

--1- 

SheetNumber 

_1_ 

-1- 

NumberOfCopies 

_ 1 _ 

NextBankTaskInfo 

.A_LJ_1 c 1 

BinFill 

Limit 

SorterBin 

Destin. 


Byte Nos. BO B2 B3 B4 B5 B6 B7 B8 B9 B10 


-3 

StitchA 

Position 

StitchB 
Position. 

Permissions 
Feeder | Destin. 

^tanualPermiss'ns 
Feeder I Destin. 

Paper j 
Type. 1 

-1 - 

PaperWidth 

PaperLength 


B11 

B12 

B13 B14 

B15 

B16 

B17 

B18 B19 

B20 B21 


FutureFmishing 

OjJtions 


Job 

Number 


Contrast 

Control 


ContrastData 

_I_ 


B22 


B23 


B24 


B25 


B26 


B27 


DEFINITION: 

PspNextBankRequest 


IdCode 

BO 

PlateMode 

B1 

PageMode 
d1 dO 

Duplex 

Simplex 

SimultaneousDuplex 

Spare 


:: = IdCode PlateMode SheetNumber 
NumberOfCopies NextBankTasklnfoA 
NextBankTaskinfoB NextBankTaskinfoC 
BindexerFiilLimit SorterBinDestination 
StitchAPosition StitchBPosition 
FeederPermissions DestinationPermissions 
ManualFeederPermissions 
ManualDestinationPermissions PaperWidth 
PaperLength PaperType 
FutureFinishingOptions JobNumber 
ContrastAction ContrastData 

:: = BO --byte 0 

:: = 03 hex 

= B1 

:: = PageMode ColorMode 
ResolutionMode 

::= d1 do 

;; = Duplex | Simplex 

I SimultaneousDuplex | Spare 

:: = 00 binary 

:: = 01 binary 

;: = 10 binary 

:: = 11 binary 
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ColorMode 

PlateDeadCycle 

62 

NotColorO 

ColorO 

d3 

NotColorl 

Colorl 

d4 

NotColor2 

Color2 

d5 

NotColorS 

Colors 

ResolutionMode 

d6 

SimplexResI 

SinnplexRes2 

67 

DuplexResI 

DuplexRes2 

SheetNumber 
B2 B3 

Undefined 

StartingSheetNumber 

NumberOfCopies 
B4 B5 

Undefined 

NumberOfCopies 

NextBankT askInfoA 

B6 

GoodSheetDestination 

d2 d1 do 


DestinationO 
Destination 1 
Destinations 
Destinations 
Destination4 
Destinations 
Destinations 
Destination? 


:: = dS d4 d3 d2 

= 000000 binary 

:: = NotColorO | ColorO 

:; = 0 binary 

:: = 1 binary 

:: = NotColorl | Colorl 

:; = 0 binary 

:: = 1 binary 

= NotColorS | Colors 

:: = 0 binary 

;: = 1 binary 

;:= NotColorS I Colors 

;: = 0 binary 

:: = 1 binary 

;:= d7d6 

= SimplexResI | SimplexRes2 

:: = 0 binary -- lOT specific 

;: = 1 binary - lOT specific 

:: = DuplexResI | DuplexRes2 

:: = 0 binary - lOT specific 

:: = 1 binary -- lOT specific 

= B2 B3 

= Undefined | StartingSheetNumber 

:: = 0000 hex -- never used 

:: = [0001 .. FFFF] hex 

:: = B4 B5 

= Undefined | NumberOfCopies 

:: = 0000 Hex 

:: = [0001 .. FFFF] hex 

:: = B6 

:: = GoodSheetDestination Feeder 
TaskFinishing 

::= d2d1d0 

= DestinationO | Destinationi 
1 Destinations | Destinations 
I Destination4 j Destinations 
j Destinations j Destination? 

= 000 binary 

:: = 001 binary 

::= 010 binary 

oil binary 
::= 100 binary 

;; = 101 binary 

::= 110 binary 

111 binary 
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Feeder 

d5 d4 d3 


FeederO 

Feederl 

Feeder2 

Feeders 

Feeder4 

Feeders 

Feeders 

Feeder? 


TaskFinishing 

dS 


Collated 

Uncollated 


NToOne 

OneToN 


NextBankTaskInfoB 

B7 


ScratchSheetDestination 

d2 d1 do 


DestinationO 
Destination 1 
Destination2 
Destinations 
Destination4 
Destinations 
Destinations 
Destination? 

StartOfJob 

dS 

No 

Yes 

EndOfJob 

d4 

No 

Yes 


dS d4 dS 

FeederO | Feederl | Feeders | 

Feeders | Feeder4 j Feeders | Feeders | 
Feeder? 

000 binary 
001 binary 
010 binary 
oil binary 

100 binary 

101 binary 

110 binary 

111 binary 

::= d?dS 

Collated | Uncollated 

0 binary 
1 binary 

NToOne | OneToN 

0 binary 
1 binary 

B? 

ScratchSheetDestination 
StartOfJob EndOfJob 
InterruptJobAsap 
ResumeInterruptedJob Spare 

d2 d1 dO 

DestinationO | Destination 1 
I Destinations | Destinations 
1 Destination4 j Destinations 
I Destinations j Destination? 

000 binary 
001 binary 
010 binary 
oil binary 

100 binary 

101 binary 

110 binary 

111 binary 

dS --This bank begins new lOT job. 

No I Yes 

0 binary 
1 binary 

d4 - If last job, start cycle down after 
StartingSheetNumber is 
successfully imaged. 

No I Yes 

0 binary 
1 binary 
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Interrupt JobAsap 

"" 

d5 --This is the 1st bank of an ASAP 
interrupt job 

d5 

= 

No 1 Yes 

No :: 

= 

0 binary 

Yes 

= 

1 binary 

ResumelnterruptedJob 


d6 -Return to the banks indicated by 
JobNumber in this message. 

d6 :: 

= 

No 1 Yes 

No :: 

= 

0 binary 

Yes :: 


1 binary 

Spare 

= 

d7 

67 :: 

= 

0 binary 

NextBankTaskInfoC 

= 

B8 

B8 :: 

= 

OffsetOptions StichingOptions 
BindingOptions UnloadOptions 

OffsetOptions 

= 

d2 dl do 

d1 do 


NoOffset 1 Bank | Set | Bin 

NoOffset 

= 

00 binary 

Bank 

= 

01 binary 

Set 

= 

10 binary 

Bin 


11 binary 

d 2 

= 

NoRecoveryOffSet ] 

RecoveryOffSet 

NoRecoveryOffSet : 


0 binary - Specifies whether one 

sheet is to be offset at the 
point of recovery. 

RecoveryOffSet : 

= 

1 binary 

StitchingOptions : 

= 

d4 d3 

d4 d3 


None 1 PortraitSingleStitch | 
LandscapeSingleStitch | 

DoubleStitch 

None 

= 

00 binary 

PortraitSingleStitch 

= 

01 binary 

LandscapeSingleStitch 


10 binary 

DoubleStitch 

= 

11 binary 

BindingOptions 

= 

d6d5 

d6d5 

= 

None 1 BindOnly | 

DoubleStitchAndBind | Spare 

None 

: = 

00 binary 

BindOnly 

: = 

01 binary 

DoubleStitch And Bind : 

; = 

10 binary 

Spare 

: = 

11 binary 

UnloadOptions 

: = 

d7 

67 : 

\ — 

UnloadAtJobComplete | 
UnloadAtMaxCapacity 

UnloadAtJobComplete ; 

; = 

0 binary 

UnloadAtMaxCapacity ; 

; = 

1 binary 


| 4f A XEROX 
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BinFillLimit , : 

r: 

B9 

B9 : 

= 

PhysicalLimit | ProgrammedLimit 

PhysicalLimit : 

= 

00 hex 

ProgrammedLirinit : 


[01 .. FF] hex -- Limits and units of 
measurement are 
destination specific. 

SorterBin Destination : 

= 

BIO 

BIO 


:: = Undefined | SorterBinNumber 

Undefined : 

; = 

00 hex 

SorterBinNumber : 


[01 .. FF] hex -- Applicable if a 

multi-bin sorter has been 
specified under 
GoodSheetDestination 

StitchAPosition ; 

: = 

B11 

B11 : 

: = 

Position 

Position : 

; = 

[00 .. FF] hex - lOTspecific 

StitchBPosition : 

: = 

B12 

B12 : 

: = 

Position 

Position : 

: = 

[00 .. FF] hex - lOT specific 

FeederPermissions 

: = 

B13 

B13 : 

: = 

Feederidentification - Defined in 

NextBankT askInfoA 

Feederidentification 

: = 

CL 

CL 

O 

do 

: = 

FeederO 

dl 

; = 

Feederl 

d2 

; = 

Feeder2 

d3 

: = 

FeederO 

d4 

: = 

Feeder4 

d5 

; = 

Feeders 

d6 

: = 

Feeders 

67 

: = 

Feeder? 

FeederO .. Feeder? 

: = 

SwitchNotPermitted | 

SwitchPermitted 

SwitchNotPermitted 

: = 

0 binary 

Switch Permitted 

:: = 

1 binary 

DestinationPermissions 

:: = 

B14 

B14 

= 

Destinationidentification -- Defined 

in NextBankTaskInfoA 

Destinationidentification 

= 

[d? .. dO] 

dO 

= 

DestinationO 

dl 

= 

Destination 1 

d 2 

= 

Destination2 

d 3 

= 

DestinationO 

d4 


Destination4 

d 5 

= 

Destinations 

d6 


Destinations 

d 7 

= 

Destination? 
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DestinationO .. 


Destination? : 

— 

SwitchNotPermitted | 

SwitchPermitted 

SwitchNotPermitted : 

= 

0 binary 

SwitchPermitted 

= 

1 binary 

ManualFeederPermissions : 

= 

B15 

B15 

= 

Feederldentification - Defined in 

NextBankT askInfoA 

Feederldentification : 

: = 

[d? .. do] 

do : 

: = 

FeederO 

d1 : 

: = 

Feederl 

d2 : 

: = 

Feeder2 

d3 : 

: = 

Feeders 

d4 : 

: = 

Feeder4 

d5 : 

: = 

Feeders 

d6 

: = 

Feeders 

d? 

: = 

Feeder? 

FeederO .. Feeder? : 

; =: 

SwitchNotPermitted 

1 SwitchPermitted 

SwitchNotPermitted 

: = 

0 binary 

SwitchPermitted : 

; = 

1 binary 

ManualDestinationPermissions : 

: = 

BIS 

B16 

I = 

Destinationidentification -- Defined 

in NextBankTaskInfoA 

Destinationidentification 

; = 

[d? .. dO] 

do 

; = 

DestinationO 

d1 

: = 

Destination! 

d2 

: = 

Destination2 

d3 

: = 

Destinations 

d4 

; = 

Destination4 

d5 

: = 

Destinations 

d6 

; = 

Destinations 

d? 

; = 

Destination? 

DestinationO .. 

Destination? 

; = 

Switch NotPermitted 

1 SwitchPermitted 

Switch NotPermitted 

: = 

0 binary 

SwitchPermitted 

; =: 

1 binary 

PaperType 

: = 

B1? 

B1? 

; = 

d?dSdSd4d3d2d1dO 

do 

: = 

NotSpecified | Specified 

NotSpecified 

: = 

0 -- default to contents of specified 
tray 

Specified 

\ =: 

1 -- as below 

d1 

: = 

NotTransparency | Transparency 

NotTransparency 

; = 

0 

Transparency 

: = 

1 
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62 

NotDrilled 

Drilled 

d7d6d5d4d3 

NotTabStock 

NumberOfTabs 

PaperWidth 

B18B19 

Default 

WidthDimension 

PaperLength 

B20B21 

Default 

LengthDimension 

FutureFinishingOptions 

B22B23 

CopySensitive 

dO 

No 

Yes 

InhibitBindexerMode 

d1 

No 

Yes 

Spares 

JobNumber 

B24 

Undefined 

Jobldentifier 

ContrastControl 

B25 

Nornnal 

Darker 

Lighter 

Programmable 

Spare 


= NotDrilled | Drilled 

= 0 
= 1 

= NotTabStock | NumberOfTabs 
::= 00000 binary 

::= [00001 ..11111] binary -- 00001 is 

full tab, 00010 is 2 
half-length tabs, etc. 

::= B18B19 

:: = Default | WidthDimension 

:: = 0000 Hex -- Whatever is in 

specified tray. 

:: = [0001 .. FFFFj hex - PaperWidth in 

mm. 

::= B20B21 

:: = Default | LengthDimension 

:: = 0000 Hex - Whatever is in 

specified tray. 

::= [0001 .. FFFF] hex - PaperLength in 

mm. 

:: = B22B23 

:: = CopySensitive InhibitBindexerMode 

Spares 

;: = do - Printed data on sheets may 

differ from copy to copy. 

:: = No I Yes 

;; = 0 binary 

:: = 1 binary 

:: = d1 ” inhibit use of bindexer 
algorithms. 

:: = No I Yes 

:: = 0 binary 

:: = 1 binary 

::= [d15.. d2] 

::= B24 

::= Undefined I Jobldentifier 

:: = 00 hex 

:: = [01 .. FF] hex 

:: = B25 

:: = Normal j Darker | Lighter | 
Programmable | Spare 

:: = 00 hex 

::= 01 
:;= 02 

;: = 03 - refer to ContrastData 

:: = [04 .. FF] hex 


aMm xerox 

Private 

Data 
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ContrastData 

B26B27 

Contrastsetting 

RESPONSE none 

APPLICATION NOTES 


::= B26B27 

::= Contrastsetting 

::= [0000 .. FFFF] hex - definition 

is lOT specific 


Refer to sections 6.4 and 6.5 for timing requirements, numbering 
and sequencing conventions, and examples of this message in 
operating sequences. 

CopyNumber is not included in this command, as jobs will 
always be programmed on set boundries. 

The convention for assigning color designations under 
PlateMode/ColorMode is as follows: For single color printing, 
usually black, ColorO shall designate the single color. For single 
hi-lite color printing, ColorO shall designate the principal color, 
usually black, and Colorl shall designate the hi-lite color. (The 
hue of the hi-lite color is lOT specific.) For multicolor hi-lite 
color printing, ColorO shall designate the principal color, usually 
black, and Colorl through Color3 shall designate lOT specific hi- 
lite colors. For full color printing, ColorO through Color3 are 
black, magenta, cyan, and yellow, respectively. 

OffsetOptions provides for offsetting sheets, sets, stacks, or 
parts of stacks in either collated or uncollated mode. Bank 
specifies that the sheets of the current bank are to be offset from 
the sheets of the previous bank. If this mode is selected in the 
first bank of a collated job with a stacker output, the copy sets 
will be offset in the stacker. It may also be used in this case to 
offset the sheets of any bank within the job. Set specifies to a 
bindexer that the collated sets are to be offset when ejected to 
the output stacker. Bin specifies that the uncollated contents of 
a bindexer bin are to be offset when ejected to the output 
stacker, and the number of sheets to be accumulated before 
ejecting is given in B9, BinFillLimit. 

BinFillLimit may apply to any destination. The limits and the units 
of measurement are destination specific. If destination switching 
is permitted (byte 14 or 16) switching must occur only when the 
specified limit has been reached. Because the sensors for the 
programmed limits may be different in different destinations, the 
BinFillLimit for the new destination should automatically default 
to the PhysicalLimit. Optionally, if the lOT has the capability, it 
may set the limit to the nearest equivalent of the original 
BinFillLimit specification. 

StitchingOptions provides for a single stitch (staple) in the upper 
left corner of either a portrait mode document, stitch A position, 
or of a landscape mode document, stitch B position. These 
stitch positions are both along the slow scan direction, which Is 
normally the long edge of a sheet. Therefore, the options also 
provide for double stitching along the long edge of either a 
portrait or landscape mode document. The default stitch 
positions are lOT specific, but offsets from these locations are 
programmable via B11 StitchAPosition and B12 StitchBPosition. 
The default positions are the outermost positions, and each 
offset moves the respective stitch location inboard along the 
long edge. Thus, symmetrically located double stitches are 
produced by specifying identical offsets for StitchAPosition and 
StitchBPosition. 
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Provision is made for the PSP to designate its expectations 
regarding the output medium which the iOT will utilize, i.e., size 
and type. The length and width parameters for paper size are 
each assigned fields two bytes long. This provides ample range 
for any U.S., ISO, or JIS paper size. Note that paper width is 
defined as the dimension in the slow-scan direction, and length 
is defined as the dimension in the fast-scan direction, regardless 
of whether the actual paper is fed in the portrait or landscape 
orientation. 

If the IOT detects a discrepancy between the paper 
characteristics specified in this message and the characteristics of 
the paper actually being fed, the IOT must report a fault. If 
detection of a parameter is not implemented in the IOT, it 
should report NotAvailable in lotOperationalInfo and ignore the 
fault reporting requirement. If a parameter is only detectable 
when paper is being fed, the IOT may change its 
lotOperationalInfo response and fault reporting stance after 
sufficient paper has been fed. Note that the IOT is not required 
to report PaperType in lotOperationalInfo; but if the type 
parameters are detectable, it must report a fault, if a discrepancy 
is found. PaperType is also intended for use by the IOT, as 
necessary, to condition its paper path to handle special media. 

Specifying a change in paper size may result in an IOT 
configuration change (refer to lotConfiguration). This may entail 
a delay, which would be managed by the IOT through 
lotStateInfo and lotOperationalInfo messages. 

The dimensions of the operational Standard Image Frame are 
determined from the Paper Size/Standard Image Frame matrix 
(refer to lotConfiguration) and the paper size specified in this 
message. 

In a gapless printer (web feed), the paper width specified in this 
message determines the dimension of page sync to be generated 
by the IOT. 

InterruptJobASAP indicates the first bank of a job which must be 
allowed to interrupt a job in process as soon as possible. This 
will typically be on a sheet boundary, but may be on a set¬ 
boundary if that is the first opportunity available to the IOT. In 
order to avoid mixing the output of the interrupting job with the 
output of the interrupted job, the PSP should, if possible, specifiy 
a destination for the interrupting job which is different from the 
destination for the interrupted job. If a different destination 
compatible with the output of the interrupting job is not 
available, the PSP should at least offset the interrupting job from 
the interrupted job. 

Resumeinterruptedjob notifies the IOT that It should resume the 
interrupted job designated by the jobNumber. All other 
parameters of the message are to be ignored. (Also refer to 
section 6,4.6, "Job Interrupt Protocol"). 

CopySensitive indicates that the printed data on sheets may 
differ from copy to copy and informs the IOT that the bindexer 
minimum-travel algorithms should not be used for sheets 
beginning with the designated SheetNumber. 

InhibitBindexerMode indicates that the bindexer mode of 
requesting multiple copies of each sheet should not be used by 
the IOT. This is specified if the PSP knows that the number of 
pages in the job exceeds the capacity of the bindexer. 



6-16 


HIGH-END IOT INTERFACE 2.2 







CLIENT LAYER PROTOCOL 


PspPrint (04) 

PARAMETERS PlateNumber (1) SheetNumber (2) CopyNumber (2) JobNumber (1) 

ORIGINATOR PSP 

FUNCTION To confirm that the PSP intends to deliver the video for the sheet number, plate 

number, and copy number specified, usually this is confirmation of the lOT's previous 
lotVideoHint. 

TRANSMISSION ORDER; 



IDCODE 

Plate 

Number 

SheetNumber 

_ . 1 .. 

CopyNumber 

I 

Job 

Number 

Byte Nos. 

80 

81 

82 B3 

B4 B5 

86 


DEFINITION: 

PspPrint 

IdCode 

BO 

PlateNumber 

B1 

PageMode 
d 1 do 

Duplex 

Simplex 

SimultaneousDuplex 
Spare 1 

PlateColor 

PlateDeadCycle 

d2 

NotColorO 

ColorO 

d3 

NotColorl 

Colorl 

d4 

NotColor2 

Color2 

d5 

NotColorS 

Colors 

ResolutionMode 

d6 

SimplexResI 

SimplexRes2 

d7 

DuplexResI 


:: = IDCODE PlateNumber SheetNumber 
CopyNumber JobNumber 

:: = BO --byte 0 

:: = 04 hex 

::= B1 

= PageMode PlateColor PlateResolution 

;:= d1 dO 

= Duplex | Simplex 

I SimultaneousDuplex | Spare 1 

:: = 00 binary 
= 01 binary 
::= 10 binary 
:; = 11 binary 

;;= d5d4d3d2 

::= 000000 binary 

:: = NotColorO j ColorO 

:: = 0 binary 
:: = 1 binary 

:: = NotColorl | Colorl 

:: = 0 binary 
:: = 1 binary 

;; = NotColor2 | Color2 

:: = 0 binary 
:: = 1 binary 

:: = NotColorO | Colors 

:: = 0 binary 
;: = 1 binary 

::= d7d6 

::= SimplexResI | SimplexRes2 

= 0 binary -- lOT specific 
:: = 1 binary -- lOT specific 

= DuplexResI | DuplexRes2 

:; = 0 binary - lOT specific 


4f A XEROX 
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DuplexRes2 
SheetNumber 
B2 B3 

SheetDeadCycle 

Sheetidentifier 

CopyNumber 
B4 B5 

SampleCopy 

Copyidentifier 

JobNumber 

B6 

Undefined 

Jobldentifier 


1 binary -- lOT specific 
B2 B3 

SheetDeadCycle | SheetIdentifierO 
0000 hex 

[0001 .. FFFF] hex 
B4 B5 

SampleCopy | Copyidentifier 
0000 hex 

[0001 .. FFFF] hex 
B6 

Undefined | Jobldentifier 
00 hex 

[01 .. FF] hex 


RESPONSE IotVideoRequest PlateNumber SheetNumber CopyNumber JobNumber 

APPLICATION NOTES 

Refer to sections 6.4 and 6.5 for timing requirements, numbering 
and sequencing conventions, and examples of this message in 
operating sequences. 

The convention for assigning color designations under 
PlateNumber/PlateColor is as follows; For single color printing, 
usually black, ColorO shall designate the single color. For single 
hi-lite color printing, ColorO shall designate the principal color, 
usually black; and Colorl shall designate the hi-lite color (the hue 
of the hi-lite color is lOT specific). For multicolor hi-lite color 
printing, ColorO shall designate the principal color, usually black; 
and Colorl through Color3 shall designate lOT specific hi-lite 
colors. For full color printing, ColorO through ColorS are black, 
magenta, cyan, and yellow, respectively. 
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PspReadIotMemory (06) 

PARAMETERS Spare(l) StartAddress (4) EndAddress (4) 

ORIGINATOR PSP 

FUNCTION To request a segment of lOT memory to be sent to the PSP in a series of 
IotWriteMemoryToPsp messages. 

TRANSMISSION ORDER: 


6 yt 0 Nos. 


ID CODE 

Spare 

StartAddress 

_I_1_1_ 

EndAddress 

_ 1 _ 1 _ 1 _ 


BO B 1 B2 B3 B4 B5 B 6 B7 B 8 89 


DEFINITION: 

PspReadIotMemory 

IdCode 

BO 

Spare 

B1 

StartAddress 

B2B3B4B5 

EndAddress 

B6B7B8B9 


:: = IdCode Spare StartAdress EndAddress 
:: = BO --byte 0 
:: = 06 hex 
;;= B1 

;: = [00 .. FF] hex 
::= B2B3B4B5 

::= [00000000 .. FFFFFFFF] hex 
:: = B6B7B8B9 

:: = [00000000 .. FFFFFFFF] hex 


RESPONSE IotWriteMemoryToPsp EndOf Block StartAddress Length Data 
APPLICATION NOTES This message is used by the PSP to initiate a memory upload from the lOT. 


PspReadIotState (07) 


PARAMETERS (None) 

ORIGINATOR PSP 

FUNCTION To request the lOT state be sent to the PSP. 
TRANSMISSION ORDER: 


ID CODE 


Byte Nos. 60 


DEFINITION: 

PspReadIotState 

IdCode 

BO 

RESPONSE IotStateINFO 


IdCode 

:;= BO -byte 0 
:: = 07 hex 
State 
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PspReadIotOperationalInfo (08) 

PARAMETERS InformationType (1) 

ORIGINATOR PSP 

FUNCTION Allows the PSP to determine the status of the lOT at any time. 
TRANSMISSION ORDER: 


ID CODE 


Information 

Typ* 


Byte Nos. 


BO 


B1 


DEFINITION: 

PspReadIotStatus 

IdCode 

BO 

InformationType 

B1 


Undefined 

TechRepClearOnlyFaults 

OperatorClearFaults 

TechRepRetryFaults 

HintMessage 

InfoMessage 

FeederOStatus 

Feeder1 Status 

Feeder2Status 

FeederOStatus 

Feeder4Status 

FeederSStatus 

FeederOStatus 

Feeder/Status 

DestinationOStatus 

Destination! Status 

Destination2Status 

DestinationSStatus 

Destination4Status 

DestinationSStatus 

DestinationOStatus 

Destination/Status 

CrashRecoveryStatus 

Spare 


: = IdCode InformationType 
: = BO --byte 0 
: = 08 hex 
: = B1 

: = Undefined | TechRepClearOnlyFaults 

I OperatorClearFaults | TechRepRetryFaults 
I HintMessage | InfoMessage | FeederOStatus 
1 Feeder! Status I Feeder2Status I 
I FeederSStatus 

I Feeder4Status I FeederSStatus | 

I FeederSStatus 

I FeedertStatus I DestinationOStatus | 

I Destination!Status 

I Destination2Status I DestinationSStatus 
I Destination4Status I DestinationSStatus 
I DestinationSStatus | Destination/StatuS 
I CrashRecoveryStatus | Spare 

:: = 00 hex 
:: = 0! hex 
:: = 02 hex 
:: = 03 hex 
:: = 04 hex 
;; = OS hex 
:: = OS hex 
:: = 07 hex 
:: = 08 hex 
:: = 09 hex 
:: = OA hex 
:: = OB hex 
:: = OC hex 
= OD hex 
:: = OE hex 
:: = OF hex 
:: = !0 hex 
:: = !! hex 
:: = !2 hex 
:: = !3 hex 
= !4 hex 
:: = !S hex 
:: = !8 hex 
::= [!7 .. FF] hex 


RESPONSE IotOperationalInfo InformationType DataWord 
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PspRequestIotDiagnostic (09) 

PARAMETERS Command (1) Utility (2) 

ORIGINATOR PSP 

FUNCTION To invoke predetermined 

TRANSMISSION ORDER: 


ParameterlD (2) ParameterValue(2) 
lOT diagnostic utility programs from the PSP. 



ID Code 

Command 

-1- 

Utility 

I 

-1- 

ParameterlD 

ParameterValue 

1 

Byte Nos. 

BO 

B1 

B2 B3 

B4 B5 

B6 B7 


DEFINITION: 

PspRequestIotDiagnostic :: = 

IdCode :: = 

BO :; = 

Command :: = 

B1 :: = 

Enter :: = 

Start :: = 

Stop = 

Exit :: = 

Read :: = 

Write :: = 

Spare :: = 

Utility :: = 

B2B3 :: = 

ParameterlD = 

B4B5 :: = 

ParameterValue :: = 

B6B7 = 

RESPONSE IotDiacnosticResponse Status Utility 


IdCode Command Utility ParameterlD 
ParameterValue 

BO -byte 0 

09 hex 

B1 

Enter ] Start | Stop | Exit | Read | Write | Spare 

00 hex 

01 hex 

02 hex 

03 hex 

04 hex 

05 hex 

[06 .. FF] hex 
B2B3 

[00..FF] - ID of lOT specific diagnostic 

utility. 

B4B5 

[0000..FFFF] - Set of parameters unique to 
Utility and Command. 

B6B7 

[0000..FFFF] - Set of parameter values. 


ParameterlD ParameterValue 

APPLICATION NOTES This command is valid at any time that the requested Utility can 

be run. The Utility invoked may perform certain diagnostics 
concurrently with the processing of user jobs, or the utility may 
supply the banks to run a diagnostic job. If the utility cannot be 
run because of priority activity in the lOT, this message shall be 
rejected via the status field of lotDiagnosticResponse (for 
example, a diagnostic job will not be run if the request is made 
while a user's job is in process). 

Enter is the command to enter the Utility program. Activity may 
or may not occur on entering the Utility. 
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Start is the command to start a Utility program which has been 
entered without starting, or to restart a Utility program which has 
been stopped. 

Stop is the command to stop a Utility which is running, without 
exiting. 

Exit is the command to leave the Utility program. If Exit is sent 
while a Utility is running, the Utility will stop and then exit. 

Read is a request for the value of the parameter listed in 
ParameterlD. (The value may also be the state of a device or the 
contents of a memory location.) 

Write is a command to change the value of the parameter listed 
in ParameterlD according to the contents of ParameterValue. 
(Write may also change the state of a device or the contents of a 
memory location.) 

When not applicable, the ParameterlD and/or ParameterValue 
fields should be 0000 Hex. 

Every Command used in byte 6 requires a response. (Refer to 
lotDiagnosticResponse.) 

Utility numbering must be in the range 1 to 999 decimal in 
accordance with the Multi-National Standard for Diagnostic 
ProgramNumbers and Status Codes (#7000P02860). 

Also refer to section 6.6. 
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PspRejectIotMessage (OB) 

PARAMETERS PspReason (1) lotStatusRejected (1) lotStatusParameterNumber (1) SheetNumber 
(2) CopyNumber (2) JobNumber (1) Spare (1) lotStatusParameterValue (variable 1 
to 4) 

ORIGINATOR PSP 

EUNCTION To inform the lOT that the status sent to the PSP is not valid at the time of receipt. 
TRANSMISSION ORDER: 



Byte Nos. B6 B7 B8 B9 ^^0 — — 


DEEINITION: 

PspRejectIotMessage 

IdCode 

BO 

PspReason 

B1 

UndefinedStatus 

IllegalSequence 

InvalidStatusParameter 

StatusBufferFull 

UnsupportedStatus 

InvalidFormat 

Spare 


= IdCode PspReason lotStatusRejected 
lotStatusParameterNumber SheetNumber 
CopyNumber JobNumber Spare 
lotStatusParameterValue 

:: = BO --byte 0 

:: = OB hex 

:;= B1 

:: = UndefinedStatus | IllegalSequence 
I InvalidStatusParameter 
j StatusBufferFull 
I UnsupportedStatus ] InvalidFormat 
j Spare 

:: = 01 hex - Status ID Code not recognized as 
valid. 

:: = 02 hex - Receipt of valid status at an 
invalid PSP state for that status. 

:: = 03 hex - lOT Status Parameter No. out of 
valid range. 

:: = 04 hex - PSP too busy to handle any 
further status at this time. 

:: = 05 hex - Status ID Code not implemented 
in this revision software. 

:: = 06 hex - too few or too many parameters 
for the valid ID code received. 

::= [07 .. FF] hex 
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lotStatusRejected 

B2 


IotConfiguration 

IotVideoHint 

IotVideoRequest 

IotVVriteMemoryTopSp 

IotStateInfo 

IotOperationalInfo 

IotDiagnosticResponse 

IotSheetDelivered 

IotRequestMemory 

IotSwitchInfo 

lotStatusParameterNumber 


SheetNumber 
B4 B5 

NotApplicable 
Sheetidentifier 
CopyNumber 
B6 B7 

NotApplicable 

Copyidentifier 

JobNumber 

B8 

NotApplicable 

Jobldentifier 

Spare 

B9 

lotStatusParameterValue 
[BIO .. B13] 


= IotConfiguration 
I IotVideoHint 
I IotVideoRequest 
I IotVVriteMemoryTopSp 
I IotStateInfo 
I IotOperationalInfo 
I IotDiagnostioResponse 
I IotSheetDelivered 
I IotRequestMemory 
j IotSwitchInfo 

:: = 81 hex 
;: = 83 hex 
= 84 hex 
;; = 86 hex 
:: = 87 hex 
;: = 88 hex 
:: = 89 hex 
:: = 8C hex 
:: = 8D hex 
:: = 8E hex 

;:= B3 

:; = [00 .. FF] hex --The number of the 

first status parameter 
sent by the lOT which 
was found to be in 
error; numbered in 
order of transmission, 
beginning with # 1. 

= B4 B5 

:: = NotApplicable | Sheetidentifer 

= 0000 

:: = [0001 .. FFFF] hex 

::= B6 B7 

= NotApplicable | Copyidentifier 

::= 0000 

:: = [0001 .. FFFF] hex 

:: = B8 

= NotApplicable | Jobldentifier 

::= 0000 

= [01 .. FF] hex 

::= B9 

::= [00 .. FF] hex 

::= [BIO.. B13] 

:: = [00 .. FFFFFFFF] hex - Status 

parameter value sent by the lOT. 
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RESPONSE IotStateInfo 

IotOperationalInfo 
APPLICATION NOTES 


MachineState Substates 
InformationType DataWord 


When Invalid Format is specified, the entry for 
lotStatusParanneterNumber should be as follows: 

If there are too few parameters, enter the number of the first 
missing parameter, i.e., the actual number of parameters 
received plus one. 

If there are too many parameters, enter the number of the 
first excess parameter, i.e., the expected number plus one. 

(Refer to section 6.3.1 for convention on parameter 
numbering.) 

SheetNumber, CopyNumber, and jobNumber should be 
specified as NotApplicable if they were not included in the 
message being rejected. 

The lotStatusParameterValue field is variable, according to the 
length of the specific parameter value to be transmitted. 


| 4|f A XEROX 
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PspSheetBankAbort (OC) 

PARAMETERS AbortType (1) SheetNumber (2) CopyNumber (2) JobNumber (1) 

ORIGINATOR PSP 

FUNCTION To abort the sheet designated by the SheetNumber and CopyNumber, and/or the 
current bank or all banks. 

TRANSMISSION ORDER: 



DEFINITION: 

PspSheetBankAbort 

IdCode 

BO 

AbortType 

B1 


SheetAbortA 

SheetAbortB 

JobAbortWithRecovery 

JobAbortWithoutRecovery 

AllJobsAbort 

Spare 
SheetNumber 
82 B3 

Undefined 

SpecifiedSheetNumber 

CopyNumber 
B4 B5 

Undefined 

SpecifiedCopyNumber 

JobNumber 

B6 


::= IdCode AbortType SheetNumber 
CopyNumber JobNumber 

::= BO -byte 0 

::= OC hex 

::= B1 

::= SheetAbortA | SheetAbortB 
I JobAbortWIthRecovery I 
I JobAbortWithoutRecovery | 

I AllJobsAbort | Spare 

::= 00 hex - Abort the specified sheet only. The 
video may be damaged. 

::= 01 hex - Abort the specified sheet only. The 
video is guaranteed white. 

::= 02 hex - if output jam occurs, attempt 

recovery of sheets preceding specified 
SheetNumber/CopyNumber. 

::= 03 hex - if output jam occurs, do not attempt 
recovery of sheets preceding specified 
SheetNumber/CopyNumber. 

::= 04 hex - Cancel all banks of all jobs and 
cycledown the lOT. 

::= [05 .. FF] hex 

::= B2 B3 

::= Undefined | Specific | Sheet Number 
::= 0000 hex 

::= [0001 ..FFFF] hex -Together with 
CopyNumber, designates sheet to be skipped, 
sheet to try again, or termination point of the 
bank. 

::= B4 B5 

::= Undefined | SpecifiedCopyNumber 
:: = 0000 hex 

:: = [0001 ..FFFF] hex - See comment under 
SheetNumber. 

::= B6 

= AllJobs I SpecifiedJobNumber 
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AllJobs :: = 0000 hex -- used with AIIJobsAbort only. 

SpecifiedJobNumber ::= [0001 ..FFFF] hex 


RESPONSE lOTSTATEINFO MachineState Substates 

APPLICATION NOTES 

In the event of a failure to image properly, the specified sheet 
may be aborted with SheetAbortA or SheetAbortB. In either 
case, this sheet will be delivered to the scratch sheet destination 
previously specified by a PspNextBankRequest. The job will 
continue with the same SheetNumber/CopyNumber. 
SheetAbortA and SheetAbortB distinguish between the quality of 
the video which has been delivered. When the video is not 
guaranteed white, certain lOTs may elect to take protective 
measures. In either case, the image is retried. Continued failure 
will be referred to the operator by the PSP. If the operator elects 
to continue, a marker image will be delivered to the output in 
place of the failed Image. 

A current job, next job, or interrupted job may be aborted. A 
previous job, i.e., one which has completed imaging but is not 
yet fully delivered to the final destination, cannot be aborted. 
When a current job is aborted, all sheets in process after and 
including the specified SheetNumber/CopyNumber may be 
diverted to the scratch sheet destination. The lOT will continue 
with the next job. If no further jobs are programmed, the lOT 
will cycle down. jobAbortWithOutRecovery is specified for a 
total abort. If the job is current, both the imaged and unimaged 
portion of the job are to be abandoned. When 
JobAbortWithRecovery is specified, the lOT must monitor 
delivery to the final destination of the sheets already imaged, and 
attempt recovery if a jam is detected. Typically, 

JobAbortWithRecovery is specified when PspSheetBankAbort is 
being used to effect a set-boundary job interrupt, and that part 
of the job already imaged must be preserved to be recombined 
with the balance of the job to be reprogrammed and printed at a 
later time (refer to section 6.4.6). The lOT completes a job 
abort, with or without recovery, by deleting all banks of the 
aborted job. When AlljobsAbort is specified, all banks of all jobs 
are deleted, and the lOT cycles down. 
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PspWriteIotMemory (OD) 

PARAMETERS EndOfBlock (1) StartAddress (4) Length (1) Data (1.. 117) 
ORIGINATOR PSP 

FUNCTION Allows the PSP to write to the lOT memory. 

TRANSMISSION ORDER: 



IDCODE 

EndOf 

Block 

StartAddress 

_I_I_I_ 

Length 

1 

Byte Nos. 

BO 

B1 

B2 

83 84 

B5 

86 

87 



j_I 

8(7 ♦ Length • 1) 


DEFINITION: 

PspWriteIotMemory 

IdCode 

BO 

EndOfBlock 

B1 

No 

Yes 

Unused 

StartAddress 

B2B3B4B5 

Length 

B6 

Data 

B7.. 


; = IdCode EndOfBlock StartAddress Length Data 
: = BO --byte 0 
: = OD hex 

: = B1 - marks the last HDLC frame of this memory block 
transfer. 

: = No I Yes | Unused 
; = 00 hex 
: = 01 hex 
: = [02 .. FF] hex 
;= B2B3B4B5 

: = [00000000 .. FFFFFFFF] hex 
:= B6 

; = [01 .. 75] hex -- Number of data bytes in this 
command.(max. = 117 decimal) 

: = B7..B(7 + LengthMinusOne) 

;= {[00 .. FF]1 .. [00 .. FF](1+ LengthMinusOne)} hex -- Variable 

number of 
bytes. 


RESPONSE None (May be response to lotRequestMemory) 

APPLICATION NOTES 


Used by the PSP, in response to lotRequestMemory, to 
download. Multiple messages may be required to transfer the 
entire block of memory. StartAddress is incremented by the 
maximum block size each time a subsequent message, for a 
given block request, is sent by the PSP. Thus, StartAddress is 
always the memory address of the first data byte in the current 
message. The EndOfBlock field is used to indicate the last 
message in the sequence for a given block request. 
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PspRequestIotAction (OE) 

PARAMETERS Device (1) Set (1) Action (1) Data (2) 

ORIGINATOR PSP 

FUNCTION To request action of the lOT regarding certain devices or procedures. 
TRANSMISSION ORDER: 



ID CODE 

Device 

Set 

Action 

Data 

_ ! 

Byte Nos. 

BO 

B1 

B2 

B3 

84 B5 


DEFINITION: 

PspRequestIotAction 

IdCode 

BO 

Device Set Action Data 
B1 B2 B3 B4B5 


LEDS 

Led Set 


LedSetOO 

LedSetOl 

LedSet02 

Spare 

LedAction 

On 

Off 

Blink 


= IdCode Device Set Action Data 
= BO --byte 0 
= OE hex 

= B1 B2 B3 B4B5 


= LEDS LedSet LedAction LedMask 

I Counters Counters CounterAction 

CounterData 

I Feeders Feeder FeederAction 

FeederData 


Destinations Destination 

DestinationAction 

DestinationData 


I IotDisplay DisplaySet DisplayAction 

DisplayData 

I ContrastControl ContrastSet 

ContrastAction 

ProgrammableData 

I Scheduler Scheduler SchedulerAction 

SchedulerData 


I finisher FinisherSet FinisherAction 

FinisherData 

I EnergySaver EnergySaverSet 

EnergySaverAction 

EnergySaverData 

I Spare 

:: = 01 hex - B1 

:: = LedSetOO | LedSetOl | LedSet02 
I Spare "B2 


= 00 hex 
= 01 hex 
= 02 hex 
= [03 .. FF] hex 

= On I Off I Blink | Spare - B3 

= 00 hex 

= 01 hex 

= 02 hex 
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spare 

:: = [OS .. FF] hex 

LedMask 

:: = [0000000000000000 .. 


.. 1111111111111111] 

Counters 

= 02 hex -- B1 

Counter 

:: = CounterOO | CounterOI | Counter02 


1 Spare -- B2 

CounterOO 

= 00 hex 

CounterOI 

= 01 hex 

Counter02 

:: = 02 hex 

Spare 

:: = [OS .. FF] hex 

CounterAction 

= CountUp | CountDown | InitVal | Disable 


1 AlphaVal | Spare -- BS 

CountUp 

:: = 00 hex 

CountDown 

= 01 hex 

InitVal 

:: = 02 hex 

Disable 

:: = OS hex 

AlphaVal: 

: = 04 hex 

Spare 

:: = [OS .. FF] hex 

CounterData 

= [00 .. 9999] decimal - B4BS 

Feeders 

= 0S hex 

Feeder 

:: = FeederO | Feederl | Feeders | Feeders 


1 Feeder4 | Feeders | Feeders [ Feeder? 

FeederO 

:: = 00 hex 

Feederl 

:: = 01 hex 

Feeder2 

= 02 hex 

Feeders 

:: = OS hex 

Feeder4 

04 hex 

Feeders 

= OS hex 

Feeders 

:: = OS hex 

Feeder? 

:: = 0? hex 

FeederAction 

= Raise | Lower | FeedFrom 

Raise 

= 00 hex 

Lower 

:: = 01 hex 

FeedFrom 

:;= 02 hex - start feeding from the designated 


feeder at the 1st opportunity. 

FeederData 

:: = [0000 .. FFFF] hex - Undefined 

Destinations 

:: = [04] hex 

Destination 

= DestinationO | Destinationi | Destinations 


1 Destinations | Destination4 | Destinations 


1 Destinations j Destination? 

Destinations 

:: = 00 hex 

Destination! 

:: = 01 hex 

Destination2 

= 02 hex 

Destinations 

:: = OS hex 

Destination4 

= 04 hex 

Destinations 

:: = OS hex 

Destinations 

= OS hex 

Destination? 

:: = 0? hex 

DestinationAction 

= Raise | Lower 

Raise 

:: = 00 hex 

Lower 

:: = 01 hex 
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DeliverTo :: 

= 02 hex - 

start delivering to the designated 


destination at the 1st opportunity. 

Destination Data : 

= [0000 .. FFFF] hex - Undefined 

IotDisplay ; 

= 05 hex 


DisplaySet : 

= 00 hex 


DisplayAction : 

= Clear | Display 

Clear : 

= 00 hex 


Display ; 

= 01 hex 


DisplayData 

= MessageNumber 

MessageNumber : 

= [0000 .. 0019] hex - lOT specific. 

The following message numbers are reserved for the use indicated. Exact text to be 

lOT specific. 

0000 : Sample request grantee 



0001 : Sample request denied 

0002 : See operator display for fault 


0003 : See operator display for set-up instructions 

ContrastControl :: 

= 06 hex 


ContrastSet : 

= 00 hex - 

not applicable 

ContrastAction ; 

= Normal | Darker | Lighter | Programmable 

1 Spare 

Normal : 

= 00 hex 


Darker : 

= 01 hex 


Lighter : 

= 02 hex 


Programmable : 

= 03 hex " 

see ProgrammableData 

Spare ; 

= [04 .. FF] hex 

ProgrammableData 

= Contrastsetting 

Contrastsetting 

= [0000 .. FFFF] hex - definition of contrast 


range is lOT specific. 

Scheduler 

: = 07 hex 


Scheduler 

: = 00 hex - 

not applicable 

SchedulerAction 

= MakeSample | Spare 

MakeSample 

: = 01 hex 


Spare 

:= [02 .. FF] hex 

SchedulerData 

= 0000 hex 

- not applicable 

Finisher 

= 08 hex 


FinisherSet 

= Bindexer 

Spare 

Bindexer 

; = 00 hex 


Spare 

: = [01 .. FF] hex 

FinisherAction 

: = PowerUp 

1 Spare 

1 PowerDown ] SetTapeLength 

PowerUp 

: = 00 hex 


PowerDown 

:= 01 hex 


SetTapeLength 

: = 02 hex 


Spare 

: = [03 .. FF] hex 
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FinisherData 

EnergySaver 

EnergySaverSet 

EnergySaverAction 

RestoreFullPower 

GoToNextLowerEnergyLevel 

Spare 

EnergySaverData 

Spare 


[0000 .. FF] hex - refer to “Application notes” 
09 hex 

00 hex - not applicable 
RestoreFullPower 

I GoToNextLowerEnergyLevel | Spare 
00 hex 
01 hex 

[02 .. FF] hex 

0000 hex - not applicable 
[OA .. FF] hex 


RESPONSE IotOperationalInfo InformationType DataField 
APPLICATION NOTES 

SCHEDULER: A MakeSample request received by the lOT when 
there are no active banks will be rejected. A MakeSample 
request received when there are active banks, will cause the lOT 
to make a sample at the first opportunity, and deliver it to the 
destination which is designated by the lOT to receive samples. 
There are two cases: 

1. The lOT is in CycledUpPrinting state and TasklnProcess 
substate: the lOT will select an opportunity in the sheet 
sequence to make a sample and then continue with the 
normal image sequence. 

2. The lOT is in CycledDownStandby state and Tasklncomplete 

substate: the lOT must cycle-up, make the sample, and then 
cycle down. To accomplish this, the PSP must follow the 
MakeSample request with 

PspRequestlotStateChange/CycleUp. When cycled~up the 
lOT Hints (refer to section 6.5) the sample image, the PSP 
responds with Print sample image, and, when appropriate, 
the lOT requests the video for the sample image. The PSP 
must send PspRequestlotStateChange/CycleDown to end the 
MakeSample operation. If any Hint messages occur for 
images following the sample image in the normal job 
sequence, the PSP must respond with Print deadcycle. 

Note that under case 20, a sample copy from an incomplete job 
is being produced; however, the job does not resume after the 
sample is made. The operator may, however, first resume the 
job and then issue a MakeSample request, in which case the 
sample will be made as in case 1. 

If the lOT is in CycledDownStandby and TaskComplete, a proof 
copy may be made by treating it as an ordinary job 

Counters: The CounterActions are to interpreted as follows: 

CountUp: the lOT is to increment the designated counter. 

CountDown: the lOT is to decrement the designated counter. 

InitVal: the lOT is to initialize the designated counter to 

the value in the CounterData field. 

Disable: the lOT is to disable, i.e., not use, the 

designated counter. 
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AlphaVal: the lOT is to initialize the designated counter 

with the code of an alpha-numeric character 
contained in the CounterData field. 

Note that CountUp, CountDown, and InitVal accommodate 
counters which are used exclusively for tallying. AlphaVal 
accommodates counters (registers) which are used exclusively to 
display characters on 7-segment displays. In the latter case, each 
message can display two characters, as represented by the two 
bytes of the CounterDataField. The character coding is to be per 
Ref. 5, section 6.2, International Reference Version. The lower 
order bit of the 7-bit character code is to be placed in bit dO of 
the byte, and the upper order bit is to be placed in bit d6. Bit 
d7 is to be 0. The characters used are to be limited to those 
suitable for 7-segment displays. 

Finisher: FinisherAction is PowerUp or PowerDown, FinisherData 
is a power down time-out in lOT specific units. Application of 
the time-out is also lOT specific. For example, if received with a 
PowerUp command, the time-out could be started when the 
finisher next receives a job that does not specify binding; if 
received with a PowerDown command, it could be started upon 
completion of a binding job In progress, or immediately if a 
binding job is not in progress. Care must be taken In assigning 
meaning to the default data, 0000 hex, since this value will always 
be sent with a PowerUp command if no other value is specified. 

When FinisherAction is SetTapeLength, FinisherData is tape 
length in lOT specific units. 
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PspRequestIotStateChange (OF) 

PARAMETERS ChangeRequested (1) 

ORIGINATOR PSP 

FUNCTION To command the lOT to change machine state. 
TRANSMISSION ORDER: 



ID CODE 

Change 

Requested 

Byte Nos. 

BO 

B1 


DEFINITION: 

PspRequestIotStateChange 

IdCode 

BO 

ChangeRequested 

B1 

do 

CycleDown 

CycleUp 

d7 d6 d5 d4 d3 d2 d1 


= IdCode ChangeRequested 
= BO --byte 0 
= OF hex 
B1 

= [d7 .. dO] 

= CycleUp I CycleDown 
= 0 binary 
= 1 binary 
= Spare 


RESPONSE IotStateInfo MachineState Substates 

APPLICATION NOTES Afterr request for machine state change, the lOT may optionally 

report the transient states CyclingUp or CyclingDown, but will 
always report the resulting final steady state (refer to IotStateInfo 
and section 6.4.1, lOT States). 
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Figure 6-1. Example of PspConfiguration command in 
information field of HDLC frame 


ORDER OF TRANSMISSION >- 

- 


HOLC FRAME- 




CONTROL->f 
FIELD 


8YTE0 

ID CODE 


INFORMATION FIELD- 

BYTE 1 
Command 


BYTE 2 

Data 


CRC 


1 1 0 0 0 0 0 

3 

0 

□ 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 


dO d7 

PspConfiguration(oi) 

dO d7 

V ERIF Y OuTPUTDeLIVER Y 

dO d7 

ReturnOutputSheetNumber 
= No 




0 

0 

□ 

0 

0 

0 

0 

0 

0 

0 

[-- 


ReturnOutputSheetNumber 
= OfLastSheet 



0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

[-- 




j ReturnOutputSheetNumber 
s OfEachSheet 

1 


-- on 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 ; 

0 

0 

— 


V ERIFY DUPUEXDELI VERY 

ReturnDupiexSheetNumber 
s No 


— 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

C-- 



Return DupiexSheetNumber 
s Yes 

-0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

— 


ScheduungOffSet 

NoOfPageSyncs s 2 
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Figure 6-2. Example of PspPrint command in information 
field of HDLC frame 


ORDER OF TRANSMISSION 

.—. HDLC FRAME 



(Simplex, Blpckl 


BYTE 2 I BYTE 3 I 


□ 

3 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

□ 


(ShMtNwmPMr ■ 1000 dee, 3E8 hex) 


BYTE 4 


I 


BYTES 


0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 


L— 


(CopyNumb^r *13 el«e, 0 h«x) 

I BYTE 6 I 


(JobNumb«r « 27 d«c, 1B h«x) 


INFORMATION FIELB—> 


-CRC 


HOLC FRAME 


\ -► 
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6.3.3 lOT Status messages 

IotConfiguration (81) 

PARAMETERS InformationType (1) DataField (4, 9, 10 or 16) 
ORIGINATOR lOT 

FUNCTION To provide the PSP with lOT configuration data. 
TRANSMISSION ORDER: 



ID Code 

Information 

Type 

-1-1-1- 

DataField 

_i_i__l_ 

, - , - 

DataField 

I 

-1- 

DataField 

I 

—I - 

DataField 

I 

Byte Nos. BO 

B1 

B2 

B3 B4 B5 

““ B10 

— 

“ B17 


DEFINITION: 

IotConfiguration 

IdCode 

BO 

InformationType DataWord 
B1 [B2 .. B16] 


Configuration 

Configinfo 


ConfigID 

DataLinkAddress 

B3 

DataLinkAckTime 

B4 


IdCode InformationType DataField 
BO -- byte 0 
81 hex 

B1 [B2 .. B16] --4 different formats 

Configuration Configinfo 
I MediaMatrix Matrixinfo 
I DestinationO Destinationinfo 
I Destination 1 Destinationinfo 
I DESTINATION2 DestinationInfo 
I Destinations Destinationinfo 
I DESTINATION4 DestinationInfo 
1 Destinations Destinationinfo 
I Destinations Destinationinfo 
I Destination? Destinationinfo 
1 FeederO FeederInfo 
1 Feeder) FeederInfo 
I FEEDER2 FeederInfo 
I Feeders FeederInfo 
I FEEDER4 FeederInfo 
I Feeders FeederInfo 
I Feeders FeederInfo 
I Feeder? FeederInfo 
1 Spare Spareinfo 

00 hex -- 1 ? byte format. 

ConfigID DataLinkAddress DataLinkAckTime 
PaperPathLength SlFlength 
PowerDownWarning Resolution 
Interrupted Jobs TotalJobs DuplexType 

ConfigInfoA BeltSpeed 

B2 

[00 .. FF] hex 
BS 

[00 .. FF] hex 
B4 

[00 .. FF] hex -- maximum, in milliseconds 
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B8 


DuplexOffset 

B9 


EndOfMatrix 

BIO 

No 

Yes 

DestinationO 
Destination 1 
DESTINATION2 

Destinations 

DESTINATION4 

Destinations 

Destinations 

Destination? 

Destinationinfo 

DevicelD 

B2 

Notlmplemented 

Parameter 

B3 

ParameterData 

B4B5 

TopTray 

Parameter 

B3 


Unassigned = 

MaxPaperWidth :: = 

WidthParameter :: = 

B4B5 :: = 

Undefined = 

WidthDimension;: = 
MaxPaperLength :: = 

Length Parameter :: = 

B4B5 = 

Undefined :: = 

LengthDimension :: = 

MinPaperWidth :: = 

WidthParameter :: = 

B4B5 :: = 

Undefined :: = 


[00 .. FF] hex - The number of page sync 
positive transitions between PspPrint and 
lotVideoRequest as required by the lOT. 

B9 

[00 .. FF] hex -- The number of page-times 
between lotVideoHint-Simplex and lotVideoHint- 
Duplex, as required by the lOT. 

BIO 

No I Yes 
00 hex 
01 hex 

02 hex - 5 byte format 

03 hex 

04 hex 

05 hex 

06 hex 

07 hex 

08 hex 

09 hex 

DevicelD Parameter ParameterData 
B2 

Notlmplemented j TopTray ] Stacker 
MultibinSorter | Bindexer | Spare 

00 hex 
B3 

00 hex - not applicable 
B4B5 

0000 hex " not applicable 

01 hex 
B3 

Unassigned | MaxPaperWidth 
I MaxPaperLength | MinPaperWidth 
j MinPaperLength | TopTray Attributes 
1 MaxCapacity | Spare 
00 hex 

01 hex 
B4B5 

Undefined ] WidthDimension 
0000 hexS 

[0001 .. FFFF] hex -- Max width in mm. 

02 hex 
B4B5 

Undefined | LengthDimension 
0000 hex 

[0001 .. FFFF] hex - Max length in mm. 

03 hex 
B4B5 

Undefined | WidthDimension 
0000 hex 
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WidthDimension 
MinPaperLength 
Length Parameter 
B4B5 

Undefined 
LengthDimension 
TopTray Attributes 
ParameterData 
B4B5 

Sequence 

didO 

Unassigned 
1 -to-N 
N-to-1 
Both 

Offset 

62 

No 

Yes 

Spare 

MaxCapacity 

NumberOfSheets 

B4B5 

Spare 

Stacker 

Parameter 

B3 


Unassigned 
MaxPaperWidth 
WidthParameter 
B4B5 
Undefined 
WidthDimension 
MaxPaperLength 
Length Parameter 
B4B5 
Undefined 
LengthDimension 
MinPaperWidth 

WidthParameter 


:;= [0001 .. FFFF] hex - Min width in mm. 

;; = 04 hex 
::= B4B5 

:: = Undefined | LengthDimension 
:: = 0000 hex 

:: = [0001 .. FFFF] hex -- Min length in mm. 

:: = 05 hex 
::= B4B5 

::= Sequence Offset Spare 
:;= dIdO 

:: = Unassigned | 1-to-N | N-to-1 | Both 

:: = 00 binary 
:: = 01 binary 
:: = 10 binary 
:: = 11 binary 

:;= 62 
;: = No I Yes 
:: = 0 binary 
:: = 1 binary 
::= [d15 .. d3] 

:: = 06 hex 

::= B4B5 

::= [0000 .. FFFF] hex 
:: = [07 .. FF] hex 
= 02 hex 
::= B3 

= Unassigned | MaxPaperWidth 
I MaxPaperLength | MinPaperWidth 
I MinPaperLength | StackerAttributes 
I MaxCapacity | Spare 

:: = 00 hex 
:: = 01 hex 
:;= B4B5 

:: = Undefined | WidthDimension 
:: = 0000 hex 

:: = [0001 .. FFFF] hex - Max width in mm. 

= 02 hex 
;:= B4B5 

:: = Undefined | LengthDimension 
:: = 0000 hex 

:: = [0001 .. FFFF] hex - Max length in mm. 
= 03 hex 
B4B5 
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B4B5 

Undefined 
Width Dimension 
MinPaperLength 

LengthParameter 

B4B5 

Undefined 

LengthDimension 

StackerAttributes 

ParameterData 

B4B5 

Sequence 

d1d0 

Unassigned 
1 -to-N 
N-to-1 
Both 

Offset 

d2 

No 

Yes 

Spare 

MaxCapacity 

NumberOfSheets 

B4B5 

Spare 

MultibinSorter 

Parameter 

B3 


Unassigned 

MaxPaperWidth 

Width Parameter 
B4B5 
Undefined 
WidthDimension 


;; = Undefined | WidthDimension 
:: = 0000 hex 

:: = [0001 .. FFFF] hex -- Min width in mm. 
:: = 04 hex 
::= B4B5 

:: = Undefined | LengthDimension 
;; = 0000 hex 

:: = [0001 .. FFFF] hex - Min length in mm. 
:: = 05 hex 
::= B4B5 

::= Sequence Offset Spare 
:;= dIdO 

:;= Unassigned | 1-to-N | N-to-1 | Both 

:: = 00 binary 
:: = 01 binary 
:: = 10 binary 
:: = 11 binary 

::= d2 

:: = No I Yes 

;: = 0 binary 

:: = 1 binary 

::= [d15 .. d31 

:: = 06 hex 

::= B4B5 

::= [0000 .. FFFF] hex 
:;= [07 .. FF] hex 
:: = 03 hex 
::= B3 

:: = Unassigned | MaxPaperWidth 

I MaxPaperLength | MinPaperWidth 
I MinPaperLength | Sorter Attributes 
I BinComplement | CapacityPerBin 
I Spare 

:: = 00 hex 
:: = 01 hex 
::= B4B5 

:: = Undefined | WidthDimension 
:: = 0000 hex 

:: = [0001 .. FFFF] hex - Max width in mm 
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MaxPaperLength 
Length Parameter 
B4B5 
Undefined 
Length Dimension 
MinPaperWidth 

WidthParameter 

B4B5 

Undefined 

WidthDimension 

MinPaperLength 

Length Parameter 
B4B5 
Undefined 
LengthDimension 
SorterAttributes 
B4B5 
Sequence 
dIdO 

Unassigned 

1-to-N 

N-to-1 

Both 

Offset 

d2 

No 

Yes 

Spare 

BinComplement 

NumberOfBins 

B4B5 

CapacityPerBin 

NumberOfSheets 

B4B5 

Spare 

Bindexer 

Parameter 


:: = 02 hex 
::= B4B5 

:: = Undefined | LengthDimension 
:: = 0000 hex 

:: = [0001 .. FFFF] hex -- Max length in mm. 

= 03 hex 
::= B4B5 

= Undefined | WidthDimension 
= 0000 hex 

= [0001 .. FFFF] hex -- Min width in mm. 
:: = 04 hex 
::= B4B5 

= Undefined | LengthDimension 
= 0000 hex 

:: = [0001 .. FFFF] hex -- Min length in mm. 
:: = 05 hex 

= Sequence Offset Spare 
::= dIdO 

::= Unassigned | 1-to-N | N-to-1 | Both 

:: = 00 binary 
:: = 01 binary 
:: = 10 binary 
:: = 11 binary 

;:= d2 

;:= No I Yes 

;; = 0 binary 

:: = 1 binary 

::= [d15 .. d3] 

:: = 06 hex 

::= B4B5 

:: = [0000 .. FFFF] hex 
:: = 07 hex 
= B4B5 - maximum 
:: = [0000 .. FFFF] hex 
:: = [08 .. FF] hex 
:: = 04 hex 
::= B3 


B3 


:: = Unassigned | MaxPaperWidth 

I MaxPaperLength | MinPaperWidth 
I MinPaperLength | BindexerAttributes 
I BinComplement | CapacityPerBin 
I Spare 
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Unassigned :: = 

MaxPaperWidth ;: = 

Width Parameter :: = 

B4B5 :: = 

Undefined :: = 

WidthDimension :: = 
MaxPaperLength :: = 

Length Parameter :: = 

B4B5 = 

Undefined :: = 

LengthDimension = 

MinPaperWidth :: = 

WidthParameter :: = 

B4B5 :: = 

Undefined :: = 

WidthDimension = 

MinPaperLength :: = 

LengthParameter = 

B4B5 :: = 

Undefined = 

LengthDimension :: = 
BindexerAttributes :: = 

B4B5 :: = 

Sequence = 

d1d0 :: = 

Unassigned :: = 

1-to-N :: = 

N-to-1 = 

Both :: = 

Offset = 

62 :: = 

No :: = 

Yes :: = 

StitchingOptions :: = 

d4d3 :: = 

None = 

PortraitSingleStitch:: = 

LandscapeSingle 
Stitch ;; = 

DoubleStitch = 


00 hex 
01 hex 
B4B5 

Undefined | WidthDimension 
0000 hex 

[0001 .. FFFF] hex - Max width in mm. 

02 hex 

B4B5 

Undefined | LengthDimension 
0000 hex 

[0001 .. FFFF] hex -- Max length in mm. 

03 hex 

B4B5 

Undefined | WidthDimension 
0000 hex 

[0001 .. FFFF] hex -- Min width in mm. 

04 hex 6 

B4B5 

Undefined | LengthDimension 
0000 hex 

[0001 .. FFFF] hex -- Min length in mm. 
05 hex 

Sequence Offset StitchingOptions 
BindingOptions Spare 

d1d06 

Unassigned | 1-to-N j N-to-1 ] Both 
00 binary 
01 binary 

10 binary 

11 binary 

d2 

No I Yes 
0 binary 
1 binary 
d4d3 

None I PortraitSingleStitch 

I LandscapeSingleStitch | DoubleStitch 

00 binary 
01 binary 

10 binary 

II binary 
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BindingOptions : 

.= dSdS 

d6d5 : 

= None 1 BindOnly | DoubleStitchAndBind 


1 Spare 

None : 

= 00 binary 

BindOnly ; 

= 01 binary 

DoubleStitchAndBind; 

= 10 binary 

Spare : 

= 11 binary 

Spare ; 

= [d15 .. d7] 

BinComplement : 

= 06 hex 

NumberOfBins : 

= B4B5 

B4B5 : 

= [0000 .. FFFF] hex 

CapacityPerBin ; 

= 07 hex 

NumberOfSheets : 

= B4B5 -- maximum 

B4B5 

= [0000 .. FFFF] hex 

Spare : 

= [08 .. FF] hex 

Spare : 

= [05 .. FF] hex - B2 

FeederO : 

= OA hex -- 11 byte format 

FeederI : 

= OB hex 

FEEDER2 ; 

= OC hex 

Feeders : 

= OD hex 

FEEDER4 : 

= OE hex 

Feeders : 

= OF hex 

Feeders 

= 10 hex 

Feeder? : 

= 11 hexS 

Feederinfo : 

= DevicelD MaxPaperWidth 


MaxPaperLength MinPaperWidth 


MinPaperLength FeederAttributes 

DevicelD 

= B2 

B2 

= Notlmplemented | Implemented 

Notlmplemented 

= 00 hex 

Implemented 

= 01 hex 

FeederAttributes 

= B3 

B3 

= Transparencies DrilledPaper Spare 

Transparencies 

= do 

do 

= No 1 Yes 

No 

= 0 binary 

Yes 

= 1 binary 

Drilled Paper 

= d1 

d1 

= No 1 Yes 

No 

= 0 binary 

Yes 

= 1 binary 
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Spare 

MaxPaperWidth 

B4B5 

MaxPaperLength 

B6B7 

MinPaperWidth 

B8B9 

MinPaperLength 

B10B11 

Spare 


= 

[d7.. 

d2] 


= 

B4B5 



= 

[0000 

.. FFFF] 

hex 

= 

B6B7 



= 

[0000 

.. FFFF] 

hex 

= 

B8B9 



= 

[0000 

.. FFFF] 

hex 

= 

B10B11 



[0000 

.. FFFF] 

hex 


[12 .. 

FF] hex 

- 


- Max width in mm. 

- Max length in mm. 

- Min width in mm. 

- Min length in mm. 


IN RESPONSE TO PspConfiguration Volunteered 

APPLICATION NOTES The formats of this message, corresponding to the four different 

InformationTypes, are as follows: 

Configuration requires 17 bytes (excluding ID Code): 


ID Code 

Configur¬ 

ation 

ConfigID 

DataLink 

Address 

DataLink 

AckTime 

PaperPath 

Length 

'-1-1 

SIFIength | 


Byte Nos. BO B1 B2 B3 B4 B5 B6 B7 


1 

PowerDownWarning 

1 

-^- 

Resolution 

. 1 

Interrupted 

jobs 

Total 

jobs 

DuplexType 

Configinfo 

1 

BeltSpeed 

1 

B8 B9 

B10 B11 

B12 

B13 

B14 

B15 

B16 B17 


All lOTs must use the default DataLinkAddress, 01 hex, until 
otherwise noted herein. 

DataLinkAckTime is the time which the lOT guarantees not to 
exceed when acknowledging (positively or negatively) a received 
data link frame which requires acknowledgement. This becomes 
the acknowledgement time-out employed by the PSP data link 
transmitting function (refer to section 5.3.9-e). 

PowerDownWarning is the minimum warning time which the lOT 
desires in advance of a scheduled power-down by the PSP. 

Interruptedjobs specifies the maximum number of job interrupts 
which the lOT can manage concurrently. Totaljobs specifies the 
maximum number of jobs of all categories combined which the 
lOT can manage concurrently. Refer to sections 6.4.3 and 6.4.6 
for definition of job types and job interrupt protocol. 

DuplexType under Configuration is to be used in conjunction 
with DuplexOffset under MediaMatrix. If DuplexType is 
RaceTrack, the PSP will use the figure stated in DuplexOffset as a 
fixed parameter. If DuplexType is Storing, the lOT must state the 
minimum offset. The PSP will use this figure as the minimum 
offset and also will infer from it the intermediate offsets to be 
used while the duplex paper path is being filled, as well as the 
maximum offset to be used when the duplex paper path is filled. 

The leading edge and trailing edge aspects of paper registration 
in PaperRegMode under configInfoA may be regarded as not 
applicable to web feed lOT's. 
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MediaMatrix requires 10 bytes (excluding ID Code): 


10 CODE 

M«dia 

Matrix 

PaparWidth 

1 

Slfwidth 

_ 1 _ 


Byt« No«. 80 81 82 83 84 85 


— 

PapaTIma 

1 Schad 
{ Offaat 

Ouplax 

Offaat 

End of 
Matrix 


86 87 

88 

89 

610 


MediaMatrix is the vehicle by which the PSP knows which 
Standard Image Frame (and related parameters) to expect when it 
specifies the paper dimensions in PspNextBankRequest. An lOT 
may implement more than one Standard Image Frame. The 
procedure for changing from one to another is lOT specific, and 
may or may not require cycling down. It is expected that many 
lOTs will implement only a single Standard Image Frame. Each 
paper width requires a separate message. The number of 
messages is, thus, generically indeterminate, so an EndOfMatrix 
field is included. An lOT must designate a Standard Image Frame 
width of zero to indicate that it is a gapless lOT and will generate 
page sync to match the paper width requested by the PSP via 
PspNextBankRequest. 

For web feed lOTs, PaperWidth is to be interpreted as web 
width. For simultaneous duplex lOTs, DuplexOffset is to be 
interpreted as the offset between imaging stations. 

Destination requires 5 bytes (excluding ID Code): 


10 CODE 

Daati nation 
Numbar 

OavIcalO 

Paramatar 

Numbar 

ParamatarOata 

1 

80 

81 

82 

83 

84 85 


Each destination parameter requires a separate message, and 
each destination requires a separate set of messages. Up to 
seven parameters per destination are prescribed herein (e.g., 
bindexer). The format provides for future expansion to 255 
parameters per destination. 

Feeder requires 11 bytes (excluding ID Code) and a separate message for each feeder in order to deliver all of 
the information: 


10 CODE 

Feeder 

Number 

OeviceiO 

Feeder 

Attributes 

-1- 

MaxPaperWidth 

_1_ 

-1.— ■ 

MaxPaperLength 

» 

00 

B1 

82 

83 

84 

B5 

B6 B7 





1 

MinPaperWidth 

_1_ 

» 

MinPaperLength 

_1_ 





B3 

89 

CD 

o 

CD 
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IotMetaReset (82) 

PARAMETERS lotStatus (2) ResetMode (1) 

ORIGINATOR lOT 

FUNCTION To inform the PSP of the specific unrecoverable error detected in the lOT and that an lOT 
reset is necessary. The lOT either requests a hardwired reset or indicates that it will reset 
itself. 

TRANSMISSION ORDER: 



DEFINITION: 

IotMetaReset 
IdCode 
BO 

lotStatus 

CourseCode 
CourseCode 
FineCode 
FineCode 
ResetMode 
B3 

SelfReset 
RequestPspReset 

IN RESPONSE TO Volunteered 
APPLICATION NOTES 

When RequestPspReset is specified in the ResetMode byte, the 
PSP is to perform a hardwired reset of the lOT by means of the 
Power Control cirduit in the physical interface. 

This message may be sent in the Un-numbered Information 
format of the HDLC frame to preclude the possibility of invoking 
the Data Link time-out and retransmission strategy during implied 
exception conditions. 



= IdCode lotStatus ResetMode 
= BO "byte 0 
= 82 hex 

= CourseCode FineCode 
= B1 

= [00 .. FF] hex - lOT specific 
= B2 

= [00 .. FF] hex - lOT specific 
= B3 

= SelfReset | RequestPspReset 
= 00 hex 
= 01 hex 
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IotVideoHint (83) 


PARAMETERS PlateNumber (1) SheetNumber (2) CopyNumber (2) JobNumber (1) 
ORIGINATOR lOT 

FUNCTION To hint the video information required for a subsequent page time of the lOT. 
TRANSMISSION ORDER: 



IDCODE 

Plate 

Number 

SheetNumber 

1 

CopyNumber 

1 

Job 

Number 

Byte Nos. 

80 

B1 

82 S3 

B4 B5 

B6 


DEFINITION: 

IotVideoHint 

IdCode 

BO 

PlateNumber 

B1 

PageMode 
d1 dO 

Duplex 

Simplex 

SimultaneousDuplex 
Spare 1 

PlateColor 

PlateDeadCycle 

d2 

NotColorO 

ColorO 

d3 

NotColorl 

Colorl 

d4 

NotColor2 

Color2 

d5 

NotColor3 

Color3 


IdCode PlateNumber SheetNumber 
CopyNumber JobNumber 

BO -byte 0 

83 hex 

B1 

PageMode PlateColor PlateResolution 

d 1 do 

Duplex I Simplex 

I SimultaneousDuplex | Sparel 

00 binary 
01 binary 
10 binary 

II binary 

d5 d4 d3d2 

000000 binary 

NotColorO I ColorO 

0 binary 
1 binary 

NotColorl I Colorl 

0 binary 
1 binary 

NotColor2 I Color2 

0 binary 
1 binary 

NotColorO I ColorO 

0 binary 
1 binary 
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ResolutionMode 

d6 


SimplexResI 

SimplexRes2 


DuplexResI 

DuplexRes2 

SheetNumber 


B2 B3 

SheetDeadCycle 

Sheetidentifier 

CopyNumber 

B4B5 

SampleCopy 

Copyidentifier 

JobNumber 

B6 

Undefined 

Jobldentifier 


d7 d6 

SimplexResI | SimplexRes2 

0 binary -- lOT specific 
1 binary -- lOT specific 

DuplexResI | DuplexRes2 

0 binary - lOT specific 
1 binary -- lOT specific 

B2 B3 -- Sheet to be committed to 

the paper path by the lOT upon 
receipt of PspPrint Command 
specifying same Sheet, Plate, 
and Copy Number. 

SheetDeadcycle | Sheetidentifier 

0000 hex 

[0001 .. FFFF] 

B4B5 - See note under 
SheetNumber 

SampleCopy [Copyidentifier 
0000 hex 

[0001 .. FFFF] hex 
B6 

Undefined | Jobldentifier 
00 hex 

[01 .. FF] hex 


IN RESPONSE TO Volunteered 

APPLICATION NOTES Refer to sections 6.4 and 6.5 for timing requirements, numbering 

and sequencing conventions, and examples of this message in 
operating sequences. 

The convention for assigning color designations under 
PlateNumber/PlateColor is as follows: For single color printing, 
usually black, ColorO shall designate the single color. For single 
hi-lite color printing, ColorO shall designate the principal color, 
usually black; and Colorl shall designate the hi-lite color (the hue 
of the hi-lite color is lOT specific). For multicolor hi-lite color 
printing, ColorO shall designate the principal color, usually black; 
and Colorl through Color3 shall designate lOT specific hi-lite 
colors. For full color printing, ColorO through Color3 are black, 
magenta, cyan, and yellow, respectively. 


XEROX 
Mgoa Private 
Data 


HIGH-END lOT INTERFACE 2.2 


6-49 











CLIENT LAYER PROTOCOL 


IotVideoRequest (84) 

PARAMETERS PlateNumber (1) SheetNumber (2) CopyNumber (2) JobNumber (1) 

ORIGINATOR lOT 

FUNCTION To request video data for the next page sync signal. The Sheet, Plate, and Copy 

number sent bythe lOT may be out ofthe normal expected order if sent to different 
output destinations. Under exception conditions, the Sheet, Plate, Copy, and Job 
number sent by the lOT may be repeated in subsequent page-times. 

TRANSMISSION ORDER: 



DEFINITION: 

IotVideoRequest 

IdCode 

BO 

PlateNumber 

B1 

PageMode 
d1 dO 

Duplex 

Simplex 

SimultaneousDuplex 

Sparel 

PlateColor 

PlateDeadCycle 

d2 

NotColorO 

CoIorO 

d3 

NotColorl 

Colorl 

d4 

NotColor2 

Color2 

d5 

NotColorS 

Colors 

ResolutionMode 

d6 

SimplexResI 

SimplexRes2 

d7 

DuplexResI 

DuplexRes2 


:: = IdCode PlateNumber SheetNumber 
CopyNumber JobNumber 

= BO -- byte 0 

;; = 84 hex 

::= B1 

::= PageMode PlateColor PlateResolution 

::= d 1 do 

= Simplex | Duplex 

I SimultaneousDuplex | Sparel 

:: = 00 binary 
:: = 01 binary 
:; = 10 binary 
:: = 11 binary 

:: = d5 d4 d3d2 
:: = 000000 binary 
::= NotColorO I ColorO 
:: = 0 binary 
:: = 1 binary 
= NotColorl | Colorl 
:: = 0 binary 
:: = 1 binary 
:: = NotColor2 | Color2 
;: = 0 binary 
:: = 1 binary 
= NotColorO | Colors 
;: = 0 binary 
:: = 1 binary 
::= d7d6 

:: = SimplexResI | SimplexRes2 
:: = 0 binary - lOT specific 
:; = 1 binary -- lOT specific 
= DuplexResI | DuplexRes2 
::= 0 binary -- lOT specific 
:: = 1 binary - lOT specific 
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SheetNumber 
B2 B3 

SheetDeadCycle 

Sheetidentifier 

CopyNumber 

B4B5 

SampleCopy 

Copyidentifier 

JobNumber 

B6 

Undefined 

Jobldentifier 


= B2 B3 

= SheetDeadcycle ] Sheetidentifier 
= 0000 hex 
= [0001 .. FFFF] hex 
= B4B5 

= SampleCopy | Copyidentifier 
= 0000 hex 
= [0001 .. FFF] hex 
= B6 

= Undefined | Jobldentifier 
= 00 hex 
= [01 .. FF] hex 


IN RESPONSE TO PspPrint PlateNumber SheetNumber CopyNumber JobNumber 

APPLICATION NOTES Refer to sections 6.4 and 6.5 for timing requirements, numbering 

and sequencing conventions, and examples of this message in 
operating sequences. 

The convention for assigning color designations under 
PlateNumber/PlateColor is as follows: For single color printing, 
usually black, ColorO shall designate the single color. For single 
hi-lite color printing, ColorO shall designate the principal Color, 
usually black; and Colorl shall designate the hi-lite color (the hue 
of the hi-lite color is lOT specific). For multicolor hi-lite color 
printing, ColorO shall designate the principal color, usually black, 
and Colorl through Colors shall designate lOT specific hi-lite 
colors. For full color printing, ColorO through ColorS are black, 
magenta, cyan, and yellow, respectively. 
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lOTWRiTEMEMORYloPSP (86) 

PARAMETERS EndOfBlock (1) StartAddress (4) Length (1) Data (1.. 117) 

ORIGINATOR lOT 

FUNCTION To transmit contents of lOT Memory to the PSP either voluntarily or as requested. 
TRANSMISSION ORDER: 



locooe 

EndOf 

Block 

StartAddress 

_I_J_I_ 

Length 

Data - 
1 

Byte Nos. 

BO 

B1 

B2 

B3 B4 

85 

B6 

87 


J_I 

B(7 * Length - 1) 


DEFINITION: 

IotMemoryReadResponse 

IdCode 

BO 

EndOfBlock 

B1 

No 

Yes 

Unused 

StartAddress 

B2B3B4B5 

Length 

B6 

Data 

B7.. 


:: = IdCode EndOfBlock StartAddress Length 
Data 

;: = BO --byte 0 
= OD hex 

:: = B1 - marks the last HDLC frame of this 
memory block transfer. 

= No I Yes | Unused 

:: = 00 hex 

:: = 01 hex 

:: = [02 .. FF] hex 

::= B2B3B4B5 

= [00000000 .. FFFFFFFF] hex 
:;= B6 

:: = [00 .. 75] hex - Number of data bytes in this 
message, (max. = 117 decimal) 

::= B7..B{7 + LengthMinusOne) 

;: = {[00 .. FF]1 .. [00 .. FF](i + LengthMinusOne)} hex 
" Variable 
number of bytes. 


IN RESPONSE TO PspReadIotMemory StartAddress EndAddress or Volunteered 
APPLICATION NOTES 


Multiple messages may be required to transfer the entire block of 
memory. The EndOfBlock field is used to indicate the last 
message in the sequence. 
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IotStateInfo (87) 

PARAMETERS MachineState (1) Siibstates (1) 

ORIGINATOR lOT 

FUNCTION To volunteer information following a power up, a major or minor lOT state change, 
detection of a fault, or in response to a PspReadIotState or 
PspRequestIotStateChange. 

TRANSMISSION ORDER: 


Byl* Not. 


10 CODE 


Mtctiino 

Stattt 


Subttatts 


80 81 82 


DEFINITION: 

IotStateInfo 

IdCode 

BO 

MachineState Substates 
B1 B2 


CycledDownStandby 

CycledDownNotReady 

Cycling Down 

CyclingUp 

CycledUpPrinting 

CycledUpNotReady 

Spare 

Substates 

dldO 

TaskStates 

TaskComplete 
T askiNPROCESS 
T askReadyForRestart 
TaskIncomplete 

d2 

FaultStates 

FaultNotDetected 

FaultDetected 

d3 

ProductivityStates 


IdCode MachineState Substates 
BO --byte 0 
87 hex 
B1 B2 

CycledDownStandby Substates 
1 CycledDownNotReady Substates 
I CyclingDown Substates 
I CyclingUp Substates 
I CycledUpPrinting Substates 

I CycledUpNotReady Substates 

00 hex 
01 hex 
02 hex 
03 hex 
04 hex 
05 hex 

[06 - FF] hex 
d7 .. do 
JobStates 

TaskComplete ] TaskiNPROCESs 
T askReadyForRestart 
TaskIncomplete 

00 binary 
01 binary 
10 binary 

II binary 

FaultStates 

FaultNotDetected 

FaultDetected 

0 binary 

1 binary 

ProductivityStates 
Productive | Nonproductive 
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Productive ;;= 0 binary 

Nonproductive ::= 1 binary 

d7d6d5d4 ::= Spare 


IN RESPONSE TO PSPREADIOTSTATE, PSPREQUESTIOTSTATECHANCE, or Volunteered 

APPLICATION NOTES This message contains the machine states and substates of an 

lOT which must be observable at the generic interface. An lOT 
may have more internal states, which need not be reported at 
the interface, but they must fall within the definitions given in the 
following section (also refer to section 6.4.1, lOT States). 

The substates are defined as follows: 

TaskComplete All sheets defined by all Banks sent to the lOT have been imaged 
and delivered to the output destination; the lOT has processed 
the Bank specifying CycleDown, and has cycled down. The 
previous task state, while cycled up and during cycle down, will 
have been TaskReadyForRestart. The TaskComplete state will also 
be entered following a PspMetaReset, a PspSheetBankAbort- 
AllBanksAbort, or a PspSheetBankAbort-ThisJobAbort, if it is the 
only Bank remaining to be processed. 

TaskInProcess The lOT is processing Banks which it has received via 
PspNextBankRequest and is printing normally. When a job is 
completed by processing a Bank specifying EndOfjob, 
TaskInProcess transitions to TaskReadyForRestart when cycle 
down begins. If the lOT receives a PspRequestStateChange- 
CycleDown during Tasklnprocess, this substate will be maintained 
until the cycle down is completed, and will then transition to 
Taskincomplete. 

TaskReadyForRestart This substate is entered when the lOT, in the CycledUpPrinting 

machine state, processes a Bank specifying EndOfjob, i.e., the 
last sheet of the last Bank has been printed and the lOT is 
delivering the previously imaged sheets to their destination. If 
this state is entered because the lOT has processed the Bank 
specifying EndOfjob, it will transition to TaskComplete when the 
cycle down is finished, including delivery' of the the last sheet of 
the last copy from a finisher. 

Taskincomplete This substate will be entered from TaskInProcess if the lOT 
completes a cycle down without completely processing the 
Bank(s) It has been given. This may be due to an interrupted job 
or to extended processing in a finisher. 

FaultNotDetected The machine has no detected faults which prevent procressing 
the current job. This substate may exist in any of the machine 
states. 

FaultDetected A fault which prevents processing the current job has been 
detected, and some action by either the Tech Rep or the 
Operator, or both, is required. The current job is the job which 
was in process and is now incomplete, or a job that has been 
requested via PspNextBankRequest. The machine will usually be 
in the CyclingDown or CycledDownNotReady state when this 
substate is reported. However, the machine may be cycled up 
for the purpose of running diagnostics while this substate exists. 
The FaultDetected substate always induces the nonproductive 
substate, as well. The details of a fault state must be reported to 
the PSP via TechRepCIearOnlyFaults, OperatorClearOnlyFaults, or 
TechRepRetryFaults of lotOperationallnfo. There may be certain 
detected.faults which do not prevent the current job from being 
procressed. Such faults must be reported via lotOperationallnfo 



6-54 


HIGH-END lOT INTERFACE 2.2 










CLIENT LAYER PROTOCOL 


Productive 


Nonproductive 


CycledDownStandby 


CycledDownNotReady 


CyclingDown 


CyclingUp 


as FaultWarnings in the HintMessage field, rather than via 
lotStatelnfo. 

The lOT is processing customer's jobs, or is available to process 
customer's jobs. Note that the lOT may also be performing 
diagnostics which do not interfere with the processing of 
customer's jobs. The diagnostic activity must be reported to the 
PSP via the HintMessage or InfoMessage of lotOperationallnfo. 

The lOT is not available for customer's jobs. The lOT has 
detected a fault, as described previously, and/or it is performing 
some nonproductive activity, such as processing diagnostic jobs, 
performing process-control, set-up, or calibration. The details of 
such nonproductive activity must be reported to the PSP via the 
HintMessage or InfoMessage of lotOperationallnfo. 

The machine states are defined as follows: 

The slow-scan mechanism is not running, the task substate is 
TaskComplete or Tasklncomplete, there are no detected faults, 
and the Productivity substate is Productive. TaskComplete 
implies that there is no longer any eventuality which would 
require re-imaging any sheet of the previous job. The lOT is 
ready to be cycled up for normal printing. In this machine state, 
Tasklncomplete implies that the PSP, for some reason, ordered 
cycle down, or the lOT, for internal reasons, initiated cycle down 
before the job in process was completed. Note that this 
machine state may change to CycledDownNotReady, if a new job 
is programmed that specifies a facility which is not ready. 

The slow-scan mechanism is not running, the task substate is 
TaskComplete or Tasklncomplete, the lOT is in the 
Nonproductive substate, and the fault substate may be 
FaultDetected or FaultNotDetected. The machine state may be 
caused to transition from CycledDownStandby to 
CycledDownNotReady, or vice versa, for example, by the 
detection of a fault or clearing of a fault, respectively, while 
cycled down, or through invoking the Nonproductive substate, 
or returning to the Productive substate, respectively, while the 
machine is cycled down. 

This is a transient state and in some lOTs may be included in the 
cycled up states. Reporting of this state is, therefore, optional. 
The slow-scan mechanism is being stopped after having been in 
the CycledUpPrinting or CycledUpNotReady machine state. 
Cycle down may be scheduled via PspNextBankRequest, or may 
be initiated via PspRequestlotStateChange or by internal lOT 
action. If the CyclingDown machine state is entered from 
CycledUpPrinting, the task substate, TaskInProcess or 
TaskReadyForRestart, will be maintained until the cycle down is 
completed, at which time the substate will transition to 
Tasklncomplete or TaskComplete, respectively. Note that when 
extended finishing is involved, the transition to TaskComplete 
must be delayed until the last sheet is delivered to the final 
destination. If the cycle-down is due to a fault, the fault substate 
will be FaultDetected. If the substates of CyclingDown are 
TaskReadyForRestart and FaultNotDetected, the lOT may be 
transitioned to machine state CyclingUp by receipt of 
PspRequestlotStateChange-CycleUp or PspNextBankRequest 
describing another job. 

This is a transient state and in some lOTs may be included in the 
cycled down states. Reporting of this state is, therefore, 
optional. The slow-scan mechanism is being started up after 
having been in the CycledDownStandby or 
CycledDownNotReady machine state. Cycle-up from 
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CycledDownStandby is normally initiated by 
PspRequestlotStateChange. The normal substates during 
CyclingUp are TasklnProcess, FaultNotDetected, and Productive. 
The lOT may enter CyclingUp from CycledDownNotReady only if 
the Productivity substate is Productive. This may be initiated by 
internal lOT action. The lOT may also enter CyclingUp from 
CyclingDown, as described above under CyclingDown. The lOT 
may be transitioned from CyclingUp to CyclingDown by receipt 
of PspRequestlotStateChange-CycleDown. 

CycledUpPrinting The slow-scan mechanism is running, the lOT is processing 
Banks, and output is being delivered. The normal substates of 
this machine state are TasklnProcess or TaskReadyForRestart, 
FaultNotDetected, and Productive. The lOT normally transitions 
to CyclingDown after processing a Bank with the EndOfJob flag 
set. The lOT may also enter CyclingDown upon receiving 
PspRequestlotAction-cycledown, or by internal action upon 
detection of a fault. 

CycledUpNotReady The slow-scan mechanism is running, the lOT is in the 

Nonproductive substate, or in an extended period of dead 
cycling between jobs. The Nonproductive substate indicates that 
some nonproductive activity is taking place which precludes 
printing a customer job, e.g., process control, calibration, set-up, 
etc. The Task substates may be TaskComplete or 
Taskincomplete, depending on the conditions existing when the 
lOT entered this machine state. The normal fault substate is 
FaultNotDetected; however, FaultDetected may exist if it does 
not preclude the cycled-up activity. 
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IotOperationalInfo (88) 

PARAMETERS InformationType (1) DataField (6, or variable 1 to 122) 

ORIGINATOR lOT 

FUNCTION To supply information in response to PspReadlotOperationallnfo, or voluntarily. 
TRANSMISSION ORDER: 



10 CODE 

Information 

Typt 

I 

Oatafisld 

1 

Oatafisid 

1 

'!.. ' ‘ " ’ 

OataFlold 
! _ 

Byt« Nos. 

60 

B1 

B2 — 

— B7 

— — 8123 


DEFINITION: 

IotOperationalInfo 

IdCode 

BO 

InformationType DataField 

B1 B2B3B4B5B6B7 .. B123 


Undefined 

TechRepGlearOnlyFaults 

NumberOfFaults 

B2 


= IdCode InformationType DataField 
= BO -- byte 0 
= 88 hex 

= B1 B2B3B4B5B6B7 .. B123 
= Undefined 

I TechRepGlearOnlyFaults 
NumberOfFaults Spare FaultCodes 
I OperatorClearFaults 
NumberOfFaults Spare FaultCodes 
I TechRepRetryFaults 
NumberOfFaults Spare FaultCodes 
I HintMessage NumberOfMessages 
Spare MessageCodes 
I InfoMessage NumberOfMessages 
Spare MessageCodes 
1 FeederO Feederinfo 
I Feeder) Feederinfo 
I FEEDER2 Feederinfo 
I FEEDER3 Feederinfo 
I FEEDER4 Feederinfo 
I Feeders Feederinfo 
I Feeders Feederinfo 
I FEEDER7 Feederinfo 
I DestinationO Destination Info 
I Destination) Destination Info 
I DESTINATION2 Destinationinfo 
I Destination3 Destinationinfo 
I Destination4 Destinationinfo 
I Destinations Destinationinfo 
I Destinations Destinationinfo 
I DESTINATION7 Destinationinfo 
I CrashRecoveryStatus LastMessage 
Crashinfo 

I Spare Spareinfo 
: = 00 hex 

: = 01 hex -- variable length format 
:= B2 

: = [00 .. 3C] hex 


XEROX 
goS Private 
Data 
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Spare 

B3 

FaultCodes 

OperatorClearFaults 

NumberOfFaults 

B2 

Spare 

B3 

FaultCodes 

TechRepRetryFaults 

NumberOfFaults 

B2 

Spare 

B3 

FaultCodes 

HintMESSAGE 

NumberOfMessages 

B2 

Spare 

B3 

MessageCodes 

InfoMessage 

NumberOfMessages 

B2 

Spare 

B3 

MessageCodes 
FeederO 
Feeder1 
FEEDER2 

Feeders 

FEEDER4 

Feeders 


::= B3 

= [00 .. FF] hex -- not sent if number of faults 
= 0 

::= B4B5 .. B(n-1)Bn -- lOT specific 2-byte 

numbers; n = (3 + 2 (number of 
faults)) for (number of faults) > 1, 
maximum = 60. 

:: = 02 hex - variable length format 
::= B2 

::= [00 .. 3C] hex 
B3 

;: = [00 .. FF] hex - see comments at 

T echRepCIearOnlyFaults 

::= B4B5 .. B(n-1)Bn 

:: = 03 hex - variable length format 

:;= B2 

::= [00 .. 3C] hex 
::= B3 

= [00 .. FF] hex - see comments at 

T echRepCIearOnlyFaults 

::= B4B5 .. B(n-1)Bn 

= 04 hex - variable length format 

:;= B2 

::= [00 .. 3C] hex 
B3 

= [00 .. FF] hex - see comments at 

TechRepCtearOnlyFaults 

::= B4B5 .. B(n-1)Bn 

;: = 05 hex - variable length format 

::= B2 

;:= [00.. 3C]hex 
::= B3 

:: = [00 .. FF] hex - see comments at 

TechRepCIearOnlyFaults 

::= B4B5 .. B(n-1)Bn 

:: = 06 hex -- seven byte format 

:: = 07 hex 

= 08 hex 

:: = 09 hex 

:: = OA hex 

:: = OB hex 


6-38 


HIGH-END lOT INTERFACE 2.2 













CLIENT LAYER PROTOCOL 

Feeders 

:: = 

OC hex 

Feeder? 

:: = 

OD hex 

Feederinfo 

— 

TrayStatus TrayPaperGauge ayPaperWidth 
TrayPaperLength 

Tray Status 

:: = 

B2 

B2 


NotAvailable | Ready Selected 

I Lowering | Lowered Jammed | Raising | 

Broken | Empty | Spare 

NotAvailable 

:: = 

00 hex 

Ready 

;; = 

01 hex 

Selected 

:: = 

02 hex 

Lowering 

:: = 

03 hex 

Lowered 

:: = 

04 hex 

Jammed 

= 

05 hex 

Raising 

:: = 

OS hex 

Broken 

:: = 

0? hex -- Not operator clearable. 

Empty 

:: = 

08 hex 

Spare 

:: = 

[09..FF] hex 

TrayPaperGauge 

:: = 

B3 

B3 

:: = 

TrayGaugeInfo 

TrayGaugeInfo 

:: = 

[00..FF] hex -- lOT specific 

TrayPaperWidth 

= 

B4B5 

B4B5 

:: = 

NotAvailable | WidthDimension 

NotAvailable 

:: = 

0000 

Width Dimension 

:: = 

[0001 .. FFFF] hex - in mm. 

TrayPaperLength 

:: = 

BSB? 

B6B7 

:: = 

NotAvailable |LengthDimension 

NotAvailable 

:: = 

0000 hex 

LengthDimension 

:: = 

[0001 .. FFFF] hex - in mm. 

DestinationO 

:: = 

OE hex -- seven byte format 

Destination 1 

:: = 

OF hex 

DESTINATION2 

:: = 

10 hex 

Destinations 

:: = 

11 hex 

DESTINATION4 

:: = 

12 hex 

Destinations 

:: = 

13 hex 

Destinations 

:: = 

14 hex 

Destination? 


15 hex 
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Destinationinfo 


DestinationStatus 

DestinationPaperGauge 

DestinationPaperWidth DestinationPaperLength 

DestinationStatus 

:: = 

B2 

B2 


NotAvailable | Ready | Selected 

1 Lowering | Lowered | Jammed | Raising 

1 Broken | Full | ReadyEmpty | Spare 

NotAvailable 

:: = 

00 hex 

Ready 

:: = 

01 hex 

Selected 

:: = 

02 hex 

Lowering 

:: = 

03 hex 

Lowered 

;; = 

04 hex 

Jammed 

:: = 

05 hex 

Raising 

;; = 

06 hex 

Broken 

:: = 

07 hex 

Full 

;; = 

08 hex 

ReadyEmpty 

;; = 

09 hex 

Spare 

;; = 

[OA .. FF] hex 

DestinationPaperGauge 

:: = 

B3 

B3 

;; = 

DestinationGaugeInfo 

DestinationGaugeInfo 

:: = 

[00 .. FF] hex -- lOT specific 

DestinationPaperWidth 

= 

B4B5 

B4B5 

:: = 

Not Available | WidthDimension 

NotAvailable 

:: = 

0000 

WidthDimension 

:: = 

[0001 .. FFFF] hex -- in mm. 

DestinationPaperLength 

:: = 

B6B7 

B6B7 

:: = 

Not Available 1 LengthDimension 

NotAvailable 

= 

0000 

WidthDimension 

:: = 

[0001 .. FFFF] hex -- in mm. 

Crash Recovery Status 

:: = 

16 hex 

LastMessage 

:: = 

B2 

B2 

:: = 

No 1 Yes 1 Unused 

No 

:: = 

00 hex 

Yes 

:: = 

01 hex 

Unused 

:: = 

[02 .. FF] hex 

Crashinfo 

:: = 

JobNumber JobState 

JobNumber 

:: = 

B3 

B3 

:: = 

Undefined | Jobldentifier 

Undefined 

:: = 

00 hex 
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Jobldentifier 
JobState 
B4 [B5 .. B9] 
Complete 
Incomplete 
Hint 

PlateNumber 


;; = [01 .. FF] hex 

:: = B4 [B5 .. B9] -- 1 or 6 bytes long 
::= Complete | Incomplete Hint 
:: = 00 hex 
= 01 hex 

= PlateNumber SheetNumber CopyNumber 
::= B5 


B5 

Page Mode 
dIdO 

Duplex : 

Simplex : 

SimultaneousDuplex 
Sparel 

PlateColor 

PlateDeadCycle 

d2 

NotColorO 

ColorO 

d3 

NotColorl 

Colorl 

d4 

NotColor2 

Color2 

d5 

NotColorS 

Colors 

ResolutionMode 

d6 

SimplexResI 

SimplexRes2 

67 

DuplexResI 
DuplexRes2 
SheetNumber 
B6 B7 


PageMode PlateColor PlateResolution 

d 1 do 

Duplex I Simplex 

I SimultaneousDuplex | Sparel 

00 binary 
01 binary 
: 10 binary 

II binary 
d5 d4 d3d2 
000000 binary 
NotColorO I ColorO 
0 binary 

1 binary 

NotColorl I Colorl 
0 binary 
1 binary 

NotColor2 I Color2 
0 binary 
1 binary 

NotColorO I Colors 
0 binary 
1 binary 
d7 d6 

SimplexResI | SimplexRes2 
0 binary -- lOT specific 
1 binary -- lOT specific 
DuplexResI | DuplexRes2 
0 binary -- lOT specific 
1 binary - lOT specific 
B6 B7 

SheetDeadCycle | Sheetidentifier 



XEROX 

Private 

Data 
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SheetDeadCycle 
Sheetldentifier 
CopyNumber 
B8 B9 

SampleCopy 

Copyidentifier 

Spare 


= 0000 hex 
= [0001 .. FFFF] hex 
= B8B9 

= SampleCopy | Copyidentifier 
= 0000 hex 
= [0001 .. FFFF] hex 
= [17.. FF] hex 


IN RESPONSE TO PspReadIotOperationalInfo Volunteered 

APPLICATION NOTES The five categories of InformationType give rise to three different 

formats for these messages. 

The Fault and Message information types require from 2 to 123 
bytes (excluding ID Code), depending on the number of fault 
codes or message codes to be transmitted; 


ID CODE 


!(Typ« o< Pauli 
I or Masaaga) 


(No. of Faults 
lor Masaagas) 


Spar# 


(HIghaat priority Fault 
or Massaga coda) 


8yta Nos. BO B1 B2 B3 B4 B5 


(Lowaat priority Fault 
or Massaga foda) 

8122 B123 


All fault (or message) codes in a particular category are included, 
in order of priority, in the data field of a single message. The 
highest priority is transmitted first. The data field will 
accommodate up to sixty fault (or message) codes. It is the 
responsibility of the lOT to prioritize the faults (or messages). If 
there are fault (or message) codes in different categories, they 
are sent in sequential messages in category code order. If there 
are no fault (or message) codes, byte B2 is 00 hex and the 
format is truncated following B2. 

(Also refer to section 6.4.8, ''Fault Protocol.") 
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Feeder and Destination information types each require 7 bytes 
(excluding ID Code): 


ID Code 

FeederN 

TrayStatus 

TrayPaper 

Gauge 

TrayPaperWidth 

_1_ 


BO 

B1 

B2 

B3 

B4 

B5 







TrayPaperLength 






B6 

B7 

ID Co(de 

DestinationN ! 

Destination 

Status 

Destination 

PaperCauge 

DestinationPaperWidth 


BO 

B1 

B2 

B3 

B4 

B5 



DestinationPaperLength 

_I_ 


B6 B7 


The CrashRecoveryStatus type requires 4 or 9 bytes (excluding 
ID Code): 



ID Code 

C rash RecoveryStatus 

LastMessage 

JobNumber 

jobState 

Byte Nos. 

BO 

B1 

B2 

B3 

B4 


PlateNumber 


SheetNumber 


CopyNumber 


B5 B6 B7 B8 B9 

After receiving a PspReadlotOperationalInfo message for 
CrashRecoveryStatus, the lOT will respond with one or more 
lotOperationalInfo messages of type CrashRecoveryStatus. Each 
message in this series will describe the crash recovery state of 
one job. The last message in this series will have "LastMessage" 
set to "Yes," which is value 01 hex. For each message, if the job 
is complete, the jobState will be "Complete" (00 hex) and that 
will be the last byte of the message. If the job's state is 
incomplete, the jobState byte will be Incomplete (01 hex). 
Following this Incomplete state byte will be the Advance Video 
Hint for that job. This hint is the PlateNumber/SheetNumber/ 
CopyNumber that the lOT would hint for that job if the lOT were 
requested to cycle up at that time. While the SheetNumber and 
CopyNumber offer possible selection of SheetDeadCycle and 
SampleCopy respectively, these are assigned for completeness 
and are never expected during the Crash Recovery exchange. 
The lOT should never volunteer this CrashRecoverStatus messge 
without first receiving a PSP request for this info. The PSP is 
allowed to request this info only between the time that the lOT 
reports a state info message after configuration exchange and 
before the first cycle up request. The PSP is not required to ask 
for the Crash Recovery exchange. The length of the job history 
that the lOT must keep is lOT specific. Some lOTs might be 
able to send a subset of the total job history in order to optimize 
Crash Recovery. This optimization is program specific. 
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The lOT may indicate either that it knows of no jobs, or was not 
able to recover any jobs, by sending the following response: 

[lotOperationalInfo (88h), CrashRecoveryStatus (16h), 
LastMessage: Yes (01 h), Crashinfo: [jobNumber: OOh, 
jobState: Complete (OOh)]] 

When the lOT sends this response, the PSP will assume that any 
jobs that it thinks are incomplete need to be remade. 
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IotDiacnosticResponse (89) 

PARAMETERS Status (1) Utility (2) ParameterlD (2) ParameterValue (2) 
ORIGINATOR lOT 

FUNCTION Returns the response to the PSP, for the requested diagnostic program. 
TRANSMISSION ORDER: 



ID Code 

Status 

-1- 

Utility 

-1- 

ParameterlD 

I 

I 

ParameterValue 

I 

Byte Nos. 

BO 

B1 

B2 B3 

B4 B5 

B6 B7 


DEFINITION: 

iotDiagnosticResponse 

IdCode 

BO 

Status 

B1 


Enter 

Start 

Stop 

Exit 

Read 

Write 

Info 

Reject 

Spare 

Utility 

B2B3 

ParameterlD 

B4B5 

ParameterValue 

B6B7 


:: = IdCode Status Utility ParameterlD 
ParameterValue 

:: = BO --byte 0 

:: = 89 hex 

::= B1 

:: = Enter | Start | Stop |Exit | Read | Write 
I Info I Reject | Spare 

:: = 00 hex - Response to Enter request. 

:: = 01 hex - Response to Start request. 

:: = 02 hex - Response to Stop request. 

:: = 03 hex - Response to Exit request. 

= 04 hex - Response to Read request. 

:: = 05 hex - Response to Write request. 

:: = 06 hex - Volunteered 
= 07 hex - Specific request rejected. 

:: = [08 .. FF] hex 
::= B2B3 
:: = [00 .. FF] hex 
:: = B4B5 

= [0000 .. FFFF] hex - Set of parmeters 

unique to utility Status. 

::= B6B7 

::= [0000 .. FFFF] hex - Set of parameter 
values. 


IN RESPONSE TO PspREQUESTIotDiagnostic Command Utility ParameterlD ParameterValue 

APPLICATION NOTES This message is defined so that when responding to 

PspRequestlotDiagnostic, it will, in general, echo the Utility and 
Command designations contained in the 

PspRequestlotDiagnostic message. For Write, the ParameterlD 
and ParameterValue are also echoed. For Read, the ParameterlD 
is echoed, and the ParameterValue is supplied. For Reject, all 
fields are echoed except the Command designation. When not 
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applicable, the ParameterlD and/or ParameterValue fields should 
be 0000 Hex. Also refer to paragraph 6.6. 

IotRE)ECTPspCom,mand (8B) 

PARAMETERS lotReason (1) PspCommandRejected (1) PspCommandParameterNumber (1) 
SheetNumber (2) CopyNumber (2) JobNumber (1) Spare (1) 
PspCommandParameterValue (variable 1 to 4) 

ORIGINATOR lOT 

FUNCTION To inform the PSP that the command sent to the lOT is not valid at the time of 
receipt. 

TRANSMISSION ORDER: 


ID Code 

lotReason 

PspCommand 

Rejected 

PspCommand 

ParamNurnber 

1 

SheetNumber 

1 


Byte Nos. BO B1 B2 B3 B4 B5 


— — 

1 

CopyNumber 

JobNumber 

Spare 

PspCommandParameterValue 

Byte Nos. 

B6 B7 

B8 

B9 

BIO — — B13 


DEFINITION: 

IotRejectPspCommand 

idCode 

BO 

lotReason 

UndefinedCommand 

IllegalSequence 

InvalidCommandParameter 

CommandBufferFull 

UnsupportedCommand 

InvalidFormat 

Spare 


IdCode lotReason PspCommandRejected 
PspCommandParameterNumber SheetNumber 
CopyNumber JobNumber Spare 
PspCommandParameterValue 

BO --byte 0 

8B hex 

B1 

UndefinedCommand | IllegalSequence 
I InvalidCommandParameter 
I CommandBufferFull 
I UnsupportedCommand | InvalidFormat 
I Spare 

01 hex - command ID Code not recognized as 
valid. 

02 hex - receipt of valid command at an invalid 
lOT state for that command. 

03 hex - PSP Command parameter number 
out of valid range. 

04 hex - lOT too busy to handle any further 
request at this time. 

05 hex - command ID Code not implemented 
in this revision software. 

06 hex - too few or too many parameters for 
the valid ID code received. 

[07 .. FF] hex 
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PspCommandRejected 

B2 


PspConfiguration 

PspNextBankRequest 

PspPrint 

PspReadIotMemory 

PspReadIotState 

PspReadIotStatus 

PspRequestIotDiagnostic 

PspSheetBankAbort 

PspWriteIotMemory 

PspRequestIot Action 

PspRequestIotStateChange 

PspCommandParameterNumber 

B3 

SheetNumber 
B4 B5 

NotApplicable 
Sheetidentifier 
CopyNumber 
B6 B7 

NotApplicable 

Copyidentifier 

JobNumber 

B8 

NotApplicable 

Jobldentifier 

Spare 

B9 

PspCommandParameterValue 
[BIO .. B13] 


B2 

PspConfiguration 
I PspNextBankReouest I PspPrint 
I PspReadIotMemory 
I PspReadIotState 
I PspReadIotStatus 
i PspReouestIotDiagnostic 
j PspSheetBankAbort 
j PspWriteIotMemory 
j PspReouestIotAction 
j PspReouestIotStateChange 

01 

03 

04 

06 

07 

08 

09 

OC 

OD 

OE 

OF 

B3 

[00 .. FF] hex -- number of the first command 
parameter sent by the PSP 
which was found to be in error. 

B4 B5 

[NoApplicable | Sheetidentifier 
0000 

[0001 .. FFFF] hex 
B6 B7 

NotApplicable | Copyidentifier 
0000 

[0001 .. FFFF] hex 
B8 

NotApplicable | Jobldentifier 
0000 

[0001 .. FFFF] hex 
B9 

[00 .. FF] hex 
[BIO .. B13] 

[00 .. FFFFFFFF] hex -Command parameter 
value sent by the PSP. 
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IN RESPONSE TO Volunteered, PSP response to be product specific. 

APPLICATION NOTES IllegalSequence includes the following cases: 

The lOT receives PspRequestlotAction/CycleUp, but has not 
properly received or stored the necessary job Bank. The lOT 
will reject the command, specify IllegalSequence, and 
designate ChangeRequested as the PspCommandParameter 
(parameter no. 1), and the CycleUp code as the 
PspCommandParameterValue. 

The PSP attempts to program too many Banks. The lOT will 
reject PspNextBankRequest, specify IllegalSequence, specify 
the appropriate SheetNumber and jobNumber parameters, 
specify CopyNumber as not applicable, and designate 
parameter no. 19 (JobNumber) as the 
PspCommandParameter, and the numerical job number as 
the PspCommandParameterValue. Note that parameter 
numbering is not the same as byte numbering (refer to 
section 3.2.1). 

W'hen Invalid Format is specified, the entry for 
PspCommandParameterNumber should be as follows: 

If there are too few parameters, enter the number of the first 
missing parameter, i.e., the actual number of parameters 
received plus one. 

If there are too many parameters, enter the number of the 
first excess parameter, i.e., the expected number plus one. 

(Refer to section 6.3.1 for convention on parameter 
numbering.) 

SheetNumber, CopyNumber, and jobNumber should be 
specified as Not Applicable if they were not included in the 
command being rejected. 

The PspCommandParameterValue field is variable, according to 
the length of the specific parameter value to be transmitted. 
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IotSheetDelivered (8C) 

PARAMETERS Integrity (1) SheetNumber (2) CopyNumber (2) Destination (1) SorterBin (1) 
JobNumber (1) 

ORIGINATOR lOT 

FUNCTION To inform PSP when each sheet has been successfully delivered to an output area, or 
whenever a scratch sheet has been delivered to an output area. 

TRANSMISSION ORDER: 


ID CODE 

\nfqriiy 

Sh««tNumbtr1 

1 

CopyNumber 

1 

Destination 

SorterBin 

Job 

Number 

80 

B1 

82 83 

84 85 

86 

87 

B8 


DEFINITION: 

IotSheetDelivered 

IdCode 

BO 

Integrity 

B1 

GoodSheet 

ScratchSheet 

Spare 

SheetNumber 

B2B3 

Undefined 

Sheetidentifier 

CopyNumber 

B4B5 

Sample 

Sheetidentifier 

Destination 

B6 


DestinationO 

Intermediate 

Final 

Destination! 

Intermediate 

Final 

DESTINATION2 

Intermediate 

Final 

Destinations 


:: = IdCode Integrity SheetNumber CopyNumber 
Destination SorterBin JobNumber 

= BO -- byte 0 

:: = 8C hex 

::= B1 

:: = GoodSheet | SoratchSheet | Spare 
:: = 01 hex 
:: = 02 hex 
::= [03 .. FF] hex 

= B2B3 -- Sheet delivered to destination. 

:: = Undefined | Sheetidentifier 
:: = 0000 hex 
:: = [0001 .. FFFF] hex 
:;= B4B5 

::= Sample I Sheetidentifier 
:: = 0000 hex 
:: = [0001 .. FFFF] hex 
;:= B6 

::= DestinationO 1 DestinationI 
I Destinations 

I Destinations | Destination4 
I Destinations 

I Destinations | Destination? | Spare 
I DuplexTray 

:: = Intermediate | Final 
;; = 80 hex 
;; = 00 hex 

:: = Intermediate | Final 
:: = 81 hex 
= 01 hex 

:: = Intermediate | Final 
:: = 82 hex 
:; = 02 hex 

:: = Intermediate | Final 
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Intermediate 

Final 

DESTINATI0N4 

Intermediate 

Final 

Destinations 

Intermediate 

Final 

Destinations 

Intermediate 

Final 

Destination? 

Intermediate 

Final 

Spare 

Intermediate 

Final 

DuplexTray 

SorterBin 

B7 

Undefined 

SorterBinNumber 

JobNumber 

B8 

Undefined 

Jobldentifier 


= 83 hex 
= 03 hex 

= Intermediate | Final 
= 84 hex 
= 04 hex 

= Intermediate | Final 
= 85 hex 
= 05 hex 

= Intermediate | Final 
= 86 hex 
= 06 hex 

= Intermediate | Final 
= 87 hex 
= 07 hex 

= Intermediate | Final 
= [88 .. 8F] hex 
= [08 .. 7F] hex 
= FFhex 
= B7 

= Undefined | SorterBinNumber 
= 00 hex 
= [01 .. FF] hex 
= B8 

= Undefined | Jobldentifier 
= 00 hex 
= [01 .. FF] hex 


IN RESPONSE TO Volunteered 

APPLICATION NOTES If PspConfiguration designates ReturnOutputSheetNumber- 

OfEachSheet, and an intermediate finishing destination is 
involved, the 8x series of hex destination codes will be returned 
as each sheet is delivered to the intermediate destination. When 
the set is ejected to the final destination, the Ox series of 
destination codes will be returned in conjunction with the last 
sheet number only. It is to be understood that whenever sheet 
number is required, the copy number must also be returned. 


I 4V& XEROX 
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IotRequestMemory (8D) 

PARAMETERS Spare (1) StartAddress (4) EndAddress (4) 

ORIGINATOR lOT 

FUNCTION To request that the PSP down load the designated segment of the lOT's software 

which is stored in the PSP's non-volatile memory, via PspWritelotMemory commands. 

TRANSMISSION ORDER: 


Byta Not. 


IDCODE 

So«r« 1 

StartAddress 

1 t 1 

EndAdd rasa 

_ 1 _ \ _1_ 


BO B1 B2 B3 B4 B5 86 87 B8 B9 


DEFINITION: 

IotRequestNonvolatileMemory 

IdCode 

BO 

Spare 

B1 

StartAddress 

B2B3B4B5 

EndAddress 


IdCode Spare StartAddress EndAddress 
BO --byte 0 
8D hex 
B1 

[00 .. FF] hex 
B2B3B4B5 

[00000000 .. FFFFFFFF] hex 
B6B7B8B9 

[00000000 .. FFFFFFFF] hex 


B6B7B8B9 

IN RESPONSE TO Volunteered 

APPLICATION NOTES The lOT may utilize non-volatile memory, which is physically located in the 

PSP. This message is used to initiate downloading. 


XEROX 
Private 
▼AV Data 
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IotSwitchInfo (8E) 

PARAMETERS Switch (1) Action (1) 

ORIGINATOR lOT 

FUNCTION To inform the PSP that the state of an external lOT switch has changed due to 


operator action. 


TRANSMISSION ORDER: 

[ 

ID CODE Switch 

Action 

Byt« Nos. 

BO B1 

B2 

DEFINITION: 

IotSwitchInfo 


:: = IdCode Switch Action 

IdCode 


:: = BO --byte 0 

BO 


::= 8Ehex 

Switch 


:;= B1 

B1 


= Start I Stop I Sample I Spare 


I Trays | Bins 
= 01 hex 
= 02 hex 
= 03 hex 
= [04 .. IF] hex 
= [20 .. 2F] hex 
= [30 .. FF] hex 
= B2 

= On I MomentaryOn | Undefined | Off 
I MomentaryOff I Undefined 
On ;; = 00 hex 

MomentaryOn ::= 01 hex 

Undefined :: = [02 .. 7F] hex 

Off :: = 80 hex 

MomentaryOff ::= 81 hex 

Undefined :: = [82 .. FF] hex 

IN RESPONSE TO Volunteered 



Start 

Stop 

Sample 

Spare 

Trays 

Bins 

Action 

B2 
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6.4 Operational protocol 


6.4.1 lOT states 


The generic states of the lOT are illustrated in figure 6-3. The 
machine states, as well as substates, are defined in the 
Application Notes for lotStateInfo. An lOT may have more 
internal states, but they must fall within the defined states. 

The two normal operating states are CycledUpPrinting and 
CycledDownStandby, Two additional steady states, 

CycledUpNotReady and CycledDownNotReady, are prescribed to 
account for exception conditions. Because some lOTs will 
require a significant time to transition between the CycledUp and 
CycledDown states, two transient states, CyclingUp and 
CyclingDown, are also prescribed. However, separate reporting 
of these states by the lOT is optional. CyclingUp may be 
included as the end of CycledDownStandby (or 
CycledDownNotReady), and CyclingDown may be included as 
the end of CycledUpPrinting (or CycledUpNotReady). Note that 
there are no distinct diagnostic modes. Diagnostics may be run 
in any of the machine states. The Productivity substate may be 
Productive or Nonproductive, depending on whether or not the 
diagnostic utility renders the lOT unavailable for customer jobs. 

The normal state transitions are from CycledDownStandby to 
CycledUpPrinting, and vice versa. If a fault occurs in 
CycledDownStandby, or if an activity is invoked which requires 
the Nonproductive substate, the machine state transitions to 
CycledDownNotReady. (The Nonproductive substate is required 
by some diagnostics and by non-job activity, such as process 
control, calibration, set-up, etc.) Similarly in CycledUpPrinting, if 
the Nonproductive substate is invoked, the machine state 
transitions to CycledUpNotReady. If due to a fault, the machine 
would normally continue on to CycledDownNotReady. If due to 
other non-job activity, the machine state could transition back to 
CycledUpPrinting when the Nonproductive substate is 
terminated. The lOT may be transitioned between 
CycledDownNotReady and CycledUpNotReady for service 
purposes, provided that a fault which precludes cycling up does 
not exist. The task substates apply only to print jobs, customer 
or diagnostic, not to the non-job activities. 

6.4.2 Message sequencing and timing requirements 

The printing of each image is accomplished by a triplet of 
Command and Status messages and a cycle of page sync. The 
messages are lotVideoHint (Hint), by which the lOT indicates to 
the PSP which image it expects next; PspPrint (Print), by which 
the PSP orders the lOT to schedule printing of the indicated 
image (usually the one expected by the lOT); and 
lotVideoRequest (Request), by which the lOT requests the video 
signal for the image designated in the Print command. For a 
given image, the messages occur in the sequence above, but 
within a page time they will bear different image indexes and 
must occur in the sequence, and according to the timing 
relationships shown in figure 6-4. Page-time is defined as the 
interval between successive positive transitions of page sync. 
(An lOT may implement more than one page-pitch, with 
corresponding page-times. The message timing requirements 
may be met by referencing each case to the respective page- 
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time, or they may be met for all cases by using the timing 
derived from the minimum page-time.) Either lotVideoRequest 
or lotVideoHint may be the first message within a given page¬ 
time, but both must occur in the first 20 percent of the page¬ 
time. lotVideoRequest must occur during the page-time 
preceding the page-time of the image being requested, so as to 
provide sufficient time for the PSP to make the appropriate image 
available at the interface. (Note that the video for the requested 
image is delivered beginning with the next positive transition of 
page sync.) The Request is accompanied by a Hint for a 
subsequent image, and then a Print for that subsequent image. 
Print must occur within the first 85 percent of the page-time, 
always following the Hint. The sheet number index of the Hint 
and Print messages must be one or more greater than the index 
of the Request occurring during the same page-time. The index 
difference, x, is the scheduling-offset, an integer equal to or 
greater than one, which represents the number of page sync 
positive transitions which must occur between the Hint (or Print) 
and Request for the same image. The scheduling-offset is the 
larger of the unique scheduling-offset requirements of the PSP 
and the lOT. The PSP will have a scheduling-offset requirement 
to allow for worst case retrieval of an image. The PSP must 
determine this offset from knowledge of the lOT paper path 
lengths (simplex and duplex), and from the PSP's resource 
management burden. The lOT will have a scheduling-offset 
requirement to allow for worst case control processing, imaging, 
and paper feeding to be completed for a given image after the 
Print command is received for that image by the lOT. The PSP 
and lOT exchange these requirements via PspConfiguration and 
lotConfiguration, respectively, and then each independently 
selects the larger for the operational scheduling-offset. The 
paper path information needed by the PSP is also conveyed by 
lotConfiguration. 

Note that although page-time is defined with reference to page 
sync and the message timing is referenced to page-time, a page 
sync true interval may not always be present at the physical 
interface for every message sequence (refer to section 6.4.4, 
Page Sync Regimen). 

The timing of PspNextBankRequest (NBR) and 
PspSheetBanf5\bort (SBA) is also specified in figure 6-3. These 
are non-repetitive messages required for initiating, controlling, 
and terminating the imaging process. NBR must occur no later 
than 0.3 of a page-time preceding onset of the page-time during 
which the Print command will occur for the image on which the 
next bank is to become effective. It may occur any time earlier. 


6.4*3 Numbering and sequencing conventions 


Four parameters are used in the numbering of sheets and images: 
PlateNumber, SheetNumber, CopyNumber, and JobNumber. 
JobNumber is used to distinguish between duplicate 
SheetNumbers which are caused by job interrupts (refer to 
section 6.4.6). The following discussion applies to non-interrupt 
conditions. It is understood that during interrupt conditions, 
JobNumber must be used in conjunction with SheetNumber to 
guarantee uniqueness. SheetNumber designates a particular 
sheet of a copy-set. CopyNumber designates the replication of 
sheets with the same image(s), or the replication of a set of 
sheets. PlateNumber is a byte code in which 2 bits denote 
which side of the sheet (simplex/duplex) is to be imaged, 4 bits 
designate in which of four colors the image is to be rendered. 
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and 2 bits designate one of two resolutions for each side of the 
sheet. Thus, the SheetNumber plus CopyNumber'' plus the 
simplex/duplex bits uniquely designate an image, the chroma bits 
designate a subset of that image, and the resolution bits 
designate the resolution of that image. SheetNumber plus 
CopyNumber^ plus PlateNumber, therefore, designates a unique 
plate. Also, SheetNumber plus CopyNumber designates a 
particular sheet of paper in the lOT. These relationships are 
shown graphically in figure 6-5 (also refer to the Glossary). 
SheetNumber zero is reserved to designate a dead cycle, i.e., a 
page-time of the lOT during which imaging (and page sync) is 
normally suspended. (Refer to section 6.4.4 for exceptions.) 
CopyNumber zero is reserved to designate a sample copy. 
When there is no ambiguity implied, the convenient terms 
'Image number" and "sheet number" are used to mean the 
designation of a unique image or a unique sheet, respectively. 
(Note that the term PlateMode rather than PlateNumber is used 
in PspNextBankRequest, because in that instance, the information 
applies to more than one particular plate.) 

Jobs are numbered consecutively in ascending order, modulo 
256, excluding zero. Zero is reserved to designate "all jobs" in 
PspSheetBankAbort. jobNumbers may exist concurrently within 
the lOT to designate previous jobs, current jobs, next jobs, and 
interrupted jobs. A previous job is one which has completed 
imaging, but not yet completed delivery to the final destination. 
There can be more than one previous job. (The implication is 
that they are relatively small jobs co-existing in the output paper 
path.) Current jobs are jobs being imaged. There can be more 
than one current job, for example, when a new job is started 
while a duplex job is still processing the duplex side of its last 
sheet(s). A next job is a job, some or all of whose parameter 
banks have been programmed into the lOT during a current job 
and is, therefore, waiting to be imaged. There can be more than 
one next job. An interrupted job is the saved banks of a job 
which has suffered an ASAP interrupt during imaging (refer to 
section 6.4.6). There can be more than one interrupted job, I.e., 
nested interrupts. The lotConfiguration message specifies the 
maximum number of interrupted jobs and the maximum number 
of jobs of all four categories combined which the lOT can 
manage. The actual capability to be implemented by an lOT is a 
design issue affecting printing productivity. For example, a 
succession of one page jobs implies a number of previous jobs 
within the output paper path of an lOT, and a number of next 
jobs programmed into the lOT, if dead cycling is to be avoided. 


^ Copy Number is required to establish uniqueness only if Change Modification Entries are used. 
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Figure 6-3. Generic lOT machine states 
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0 

0 
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Figure 6-4. Tinning windows for PSP commands and lOT 
status messages 
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Figure 6-5. Numbering convention 
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Sheets are numbered consecutively in ascending order, modulo 
65,536, excluding zero. Zero is reserved to designate "dead 
cycle" in the imaging messages. SheetNumbers run 
consecutively from job to job. The consecutive rule is abrogated 
when SheetNumbers are reused in conjunction with 
CopyNumber in multicopy jobs, and in conjunction with 
jobNumber for interrupt jobs, (refer to section 6.4.6). The 
SheetNumbers of sheets within a collated set, or an uncollated 
stack, are always in ascending order, as delivered to the final 
destination. If SheetNumber j is the last sheet delivered in the 
previous job, then SheetNumber j + 1 is the first sheet delivered 
in the current job, regardless of whether it is to be the first or 
last logical page of the output document. Image numbers 
(SheetNumber plus -p/ex bits) are also reused for multiplate 
images. SheetNumber may be reset between jobs which are 
separated by a normal cycle-down. 

jobs are characterized as 1-to-N or N-to-1, according to the 
input/output sequencing used. These terms refer to the order in 
which the logical pages of a document are handled, assuming 
that they are numbered according to the normal English reading 
sequence, jobs must be processed in 1-to-N order to output 
destination devices which stack paper face down, so as to 
maintain the proper page sequence. N-to-1 order must be used 
when the output is stacked face up. job files may be delivered 
to the PSP in either 1-to-N or N-to-1 order. A PSP may reverse 
the order for printing, if it can first absorb the entire job file. In 
1-to-N jobs, the value of N is usually not known prior to the start 
of job processing, in which case end-of-job must be 
programmed via a PspNextBankRequest toward the end of the 
job. In a 1-to-N job, image numbering corresponds directly to 
the logical page numbering of the document. Thus, the lowest 
image number represents the first logical page of the output 
document from the human reader's viewpoint. Note that though 
the images are processed in the general order 1-to-N (or N-to-1), 
they may be printed temporarily out of sequence, according to 
the requirements of the lOT to maintain maximum productivity 
with duplex paper paths and complex output collation devices. 
In any case, within a copy set, they are always in the proper 
sequence in the final output. 

In N-to-1 printing jobs, the value of N is usually known prior to 
the start of job processing, so that end-of-job could be 
programmed via a PspNextBankRequest at the beginning of the 
job. In N-to-1 reprographic jobs, however, the value of N may 
not be known prior to the start of job processing, if the source is 
an unknown number of documents in the document handler of a 
scanner. For this reason, the image numbering of N-to-1 jobs 
must always be the inverse of the logical page numbering of the 
document, i.e., the lowest image number represents the last 
logical page of the output document from the human reader's 
viewpoint. End-of-job may be programmed via a 
PspNextBankRequest whenever N becomes known, which may 
be toward the end of reprographic jobs. 

The sequence mode of each destination device is conveyed to 
the PSP in lotConfiguration. Note that some output devices may 
accept either sequence. In this case, the sequence is determined 
by the designation in the NextBankTasklnfoA parameter of 
PspNextBankRequest. 

This numbering and sequencing convention accommodates lOTs 
with complex relationships between image scheduling and sheet 
scheduling, as well as those with simple relationships. 
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6.4.4 Page sync regimen 

For purposes of this discussion, the term page sync will be taken 
to mean the page sync true interval which defines the slow scan 
dimension of the Standard Image Frame. 

Each lOT must be designed so as to enable implementation of 
either of the following page sync regimens, according to the 
needs of the PSP with which it is to be associated. 

a) Discrete regimen: 

Page sync must occur at the physical interface for every real 
image. Page sync must not occur at the physical interface for 
dead cycles. Note, however, that during processing of a job, 
machine cycles which would otherwise be dead cycles may 
be utilized for on-line diagnostics during which a test image 
is sent to the lOT. Machine cycles which are utilized in this 
manner are considered to be test cycles rather than dead 
cycles, and are legitimately accompanied by page sync. 
Once the client layer Imaging message sequence begins for a 
job, the sequence must continue for every page-time 
throughout the job, including dead cycles. Page sync must 
not occur at the physical interface at any time unrelated to 
the client layer message sequence, unless enabled during a 
Nonproductive substate invoked by PspRequestlotDiagnostic 
and/or reported via lotStatelnfo. It is shown in section 6.5 
that during cycle-up, cycle-down, and dead cycles which 
occur while printing, imaging messages occur in the absence 
of page sync at the physical interface. But these messages 
must be related, as prescribed in section 6.4.2, to the 
stabilized page-time sequence internal to the lOT, so that 
they bear a known timing relationship to preceding and/or 
following page syncs. 

b) Continuous regimen: 

Page sync must begin as soon as possible after cycle-up, but 
no later than one page time prior to delivery of the first 
image, i.e., concurrently with the first lotVideoRequest status 
message, and must occur concurrently with every subsequent 
lotVideoHint status message regardless of whether or not the 
same page sync interval contains an lotVideoRequest 
message, or whether or not the related lotVideoRequest 
message is for a dead cycle. Once the client layer imaging 
message sequence begins for a job, the sequence must 
continue for every page-time throughout the job, including 
dead cycles. 
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6.4.5 Client layer intialization (refer to figure 6-6) 


Assume that the Data Link has been established, as outlined in 
section 5.4. The PSP waits for the lOT to initiate the Client Layer 
communications (this wait should be timed out from the end of 
Data Link initialization). The lOT may begin with 
lotRequestMemory, if the lOT’s software must be downloaded. 
The PSP response is PspWritelotMemory. There may be multiple 
requests from the lOT, with corresponding responses from the 
PSP. (If there is no request from the lOT, the PSP does not write 
lOT memory.) When the lOT has all of its required memory, it 
volunteers lotStateInfo (probably CycledDownNotReady at this 
point) and waits for PspConfiguration. The first PspConfiguration 
message requests ReturnlotConfiguration. This request is sent 
first because the PSP needs the lOT Duplex Offset information in 
order to formulate its own SchedulingOffset requirement. The 
lOT responds accordingly with the full sequence of messages 
which constitute all of the lotConfiguration information. (The end 
of the sequence can be determined by the PSP from the 
contents of the messages. The number of InformationTypes is 
defined herein, and the number of entries under each type is 
either defined, or, the last entry is identified.) The PSP follows 
with its configuration information in a series of four 
PspConfiguration messages. The lOT next volunteers the full 
complement of operational information via multiple 
lotOperationalInfo messages. The PSP waits, and, when ready, 
the lOT volunteers lotStateInfo-CycledDownStandby. The printer 
is now ready to cycle-up and print. 

6.4.6 job interrupt protocol 


Job interrupts which are to occur on a set-boundary (of a 
collated job) or a stack-boundary (of an uncollated job), will be 
handled by the PSP. The PSP will issue a PspSheetBankAbort 
specifying JobAbortWithRecovery and specifying a 
SheetNumber/CopyNumber that corresponds to the first sheet of 
the next set, or stack, of the job. This will effectively terminate 
the current job at the next set, or stack, boundary. The PSP will 
then program the interrupting job as any other job, i.e., it will be 
assigned the next unused jobNumber in the sequence, and the 
lOT will not be aware that a job interrupt has occurred. It is the 
PSP's responsibility to re-program the remaining sets, or stacks, 
of the interrupted job, sometime after completion of the 
interrupting job. The reprogrammed part of the interrupted job 
is assigned the next jobNumber in sequence at the time of re¬ 
programming. (This may or may not be next in sequence to the 
interrupting jobNumber, depending on whether or not the 
interrupted job is re-programmed immediately, and whether or 
not any next jobs are queued.) Thus, the re-programmed 
portion of the interrupted job also appears to the lOT as any 
other job. Note that this protocol supports nested set-boundary 
and/or stack-boundary interrupts solely under control of the PSP, 
up to the limit of the PSP to manage the job queue. 

job interrupts which must occur as-soon-as-possible (ASAP), will 
be handled jointly by the PSP and the lOT. The probability is 
that the interrupt will occur on a page-boundary of a collated set, 
or between copies in an uncollated stack. The interrupting jobs 
are assumed to be priority jobs, which must be scheduled by the 
lOT at the earliest opportunity. The PSP must program the 
interrupting job via a PspNextBankRequest, specifying 
interruptjobAsap, specifying offset or, preferably, a different 
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destination than the interrupted job, specifying a SheetNumber 
next in sequence to the last SheetNumber hinted by the lOT, 
and specifying the next unused JobNumber in the sequence. At 
its first opportunity, the lOT must issue an lotVideoHint 
specifying the first SheetNumber/CopyNumber and JobNumber 
of the interrupting job. If the lOT cannot effect the interrupt 
within one page-time, the first SheetNumber(s) of the 
interrupting job will duplicate the last SheetNumber(s) of the 
interrupted job; however, the jobNumbers remove any 
ambiguity. The last sheet of the interrupting job will be 
programmed as usual, i.e., PspNextBankRequest specifying 
EndOfJob and the appropriate SheetNumber with the interrupting 
JobNumber. The PSP will tell the lOT to resume the interrupted 
job by programming a PspNextBankRequest specifying 
Resumelnterruptedjob and specifying the JobNumber of the 
interrupted job. (All other parameters of this message are to be 
ignored by the lOT.) The lOT is responsible for logging the 
parameters of the interrupt point, for maintaining all banks of the 
interrupted job during the interrupt, and for resuming the 
interrupted job with an lotVideoHint for the next 
SheetNumber/CopyNumber following that of the last sheet which 
was printed and delivered to the output destination before the 
interrupt took effect. (An ASAP interrupt of a collated job is 
illustrated in section 6.5.) Note that this protocol supports 
nested ASAP interrupts up to the capacity of the lOT to store the 
context and banks of interrupted jobs, or as limited by the 
number of different destinations available. 
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Figure 6-6. Client layer initialization 
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6.4.7 Crash recovery protocol 


If the lOT crashes or stops operating for any reason, it attempts 
to send an lotMetaReset/SelfReset message to the PSP. The 
accompanying Data Link procedure depends on whether Data 
Link communication is possible. If it is, lotMetaReset/SelfReset is 
sent successfully and the lOT performs the reset. After receiving 
lotMetaReset/SelfReset, the PSP Client Layer should request its 
Data Link to send the Disconnect command, and the lOT must 
then place its Data Link entity in the Asynchronous Disconnect 
Mode (ADM) according to the procedures in paragraph 5.4.4. (If 
Disconnect is not received from the PSP, the lOT Data Link 
should send Request Disconnect to elicit the Disconnect 
command from the PSP.) If Data Link communication is not 
possible, lotMetaReset/SelfReset transmission will fail. The lOT 
must then proceed with the reset and unilaterally place its Data 
Link entity in ADM. The PSP, having either sent the Disconnect 
command or detected the loss of Data Link communication, 
should periodically have its Client Layer request its Data Link to 
attempt to re-establish Data Link communications according to 
the procedures in section 5.4. When Data Link communication 
has been restored, the Client Layer is re-initialized using the 
initialization procedure of section 6.4.5. Following Client Layer 
re-initialization, the PSP optionally requests crash recovery status 
from the lOT by sending PspReadlotOperational 
Info/CrashRecoveryStatus (to which the lOT responds by sending 
one or more lotOperationalInfo/CrashRecoveryStatus). Finally, 
the PSP initiates job recovery by sending 
PspRequestlotAction/CycleUp, and the lOT must then send 
lotVideoHint for the appropriate image. This can always be 
done, since the lOT must save its context and parameter banks in 
non-volatile memory prior to hinting images from those banks. 

If the PSP crashes or stops operating for any reason, the PSP 
attempts to send a PspMetaReset command to the lOT. The 
accompanying Data Link procedure depends on whether or not 
Data Link communication is possible, if it is, PspMetaReset is 
received successfully and the lOT must then perform the reset. 
After successfully sending PspMetaReset, the PSP Client Layer 
should request its Data Link to send the Disconnect command. 
The lOT must then place its Data Link entity in the Asynchronous 
Disconnect Mode (ADM) according to the procedures in 
paragraph 5.4.4. (If Disconnect is not received from the PSP, the 
lOT Data Link should send Request Disconnect to elicit the 
Disconnect command from the PSP.) If Data Link communication 
is not possible, PspMetaReset will not be received. When the 
lOT detects loss of Data Link communications, it must perform a 
reset and unilaterally place its Data Link entity in ADM. In either 
case, the lOT must take action to empty the paper path and 
cycle down, and to preserve its context and parameter banks. If 
the PSP crashes, the lOT must not introduce any spurious paper 
into the paper path nor produce any spurious output. Upon 
reload of the PSP software, the PSP attempts to re-establish Data 
Link communication according to the procedures in section 5.4. 
After Data Link communication is established, the lOT re¬ 
initializes the Client Layer as described in section 6.4.5. The PSP 
optionally requests crash recovery status from the lOT by sending 
PspReadlotOperationalInfo/CrashRecoveryStatus (to which the 
lOT responds by sending one or more 
lotOperationallnfo/CrashRecoveryStatus). Finally, the PSP initiates 
job recovery by sending PspRequestlotAction/CycleUp, and the 
lOT must then send iotVideoF^int for the appropriate image. 
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Although the PSP periodically saves its context, it must depend 
on the lOT to recover jobs, since only the lOT can know with 
certainty the state of the paper path following the PSP's crash. 


6.4.8 Fault protocol 


Only those lOT conditions which warrant an lOT state change or 
substate change, or which warrant preventing an lOT state 
change or substate change, are to be considered faults. The PSP 
must be given notice of the occurance of any detectable fault or 
faults via an lotStateInfo message, and the identity of the fault or 
faults must be conveyed to the PSP as FaultCode(s) in one or 
more lotOperationallnfo messages. When multiple faults occur, 
either simultaneously or sequentially, lotStateInfo need be sent 
only once to notify of the initial state and/or substate change. 

Those detectable lOT conditions which do not prevent the 
current job from being processed, but which represent an 
impending fault condition, should be classified as fault warnings 
and sent initially under the HintMessage InformationType of 
lotOperationallnfo. They should be elevated to detected faults 
when a threshold of the monitored parameter and/or other 
appropriate parameter is exceeded. (The appropriate parameter 
may be, for example, time.) Those faults detected in a device or 
facility of the lOT not employed in the current job (and which do 
not pose a hazard to machine or operator), should also be 
classified as fault warnings and reported via HintMessage. If and 
when said device or facility is selected for use, a fault should be 
reported, as described above. 

It is desirable that correction of the physical condition which has 
been detected as a fault, should clear the related fault indication 
from the lOTs fault handler. If there are no remaining faults, this 
will cause a substate change (from FaultDetected to 
FaultNotDetected), which must be reported via an lotStateInfo 
message and an updated lotOperationalInfoMessage. If there are 
remaining faults, there will be no substate change, but an 
lotOperationallnfo message must still be sent to indicate the 
updated list of remaining faults. 

It is recognized that clearing a fault indication as a result of 
correcting the physical condition may not be feasible, when 
detection of a fault causes transition to a state in which the 
monitored condition ceases to exist. (In such a case, correction 
of the fault condition could be verified only by returning, or 
attempting to return, to the state in which the fault was initially 
detected.) When such faults occur, the lOT should automatically 
clear the fault indication from its fault handler immediately after It 
is reported across the interface. Thus, the PSP will be notified of 
the related lOT state or substate change and its cause, but will 
be left unincumbered by a persisting fault report. The PSP will, 
therefore, be free to attempt to proceed, following the next 
appropriate operator action. If the fault condition persists, it will 
again be detected, again cause the state change, and again be 
reported across the interface. It is suggested that when a fault of 
this class is reported and then cleared as described above, the 
User Interface should maintain display of the fault, but advise the 
operator that it is permissible to attempt to resume operations. 
Resuming should cause the fault display to disappear. It would 
subsequently reappear or not, depending on whether the fault 
condition persisted or not. This procedure is intended to 
provide an acceptable degree of conformity with the philosophy 
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that fault conditions should be perceived to be corrected by 
operator action. 

Note: In the foregoing, the term operator is used in the broad 
sense of anyone operating the system. 


6.5 Operating sequences, illustrated examples 


The purpose of the following discussion is to illustrate typical 
operational sequences involving Client Layer messages and 
interface signals. The discrete page sync regimen described in 
paragraph 6.4.4 is assumed throughout. A large number of 
different sequences is possible. The differences depend on 
whether the job is simplex only, duplex only, or combination 
simplex-duplex. The differences will also be lOT specific, 
depending on the scheduling offset (defined above), the length 
of the duplex paper path (if present), whether or not the duplex 
path temporarily stores sheets, whether or not the output is to 
be collated, and on the requirements of the finishing station. 
The following examples assume processing of a single collated 
copy to a simple stacker. Scheduling Offset = 1, and a storing 
duplex paper path of length 9, i.e., minimum Duplex Offset = 9. 
Appendix B shows the equivalent set of sequences when the 
Scheduling Offset is 3. Appendix C shows processing of 
multiple collated copies to a bindexer output. The imaging 
messages, lotVideoHint, PspPrint, and lotVideoRequest, contain 
four numbering parameters: PlateNumber, SheetNumber, 
CopyNumber, and jobNumber. For simplicity, the accompanying 
figures omit those numbers which are not pertinent to the 
example. 


6.5.1 Cyde-up sequence 


Figure 6-7-a illustrates a simplex cycle-up sequence. It is 
assumed that both the Data link and the Client Layer have been 
initialized, as described in sections 5.4.1, 5.4.2, and 6.4.5. The 
PSP first sends one or more PspNextBankRequests to program 
the job. This is followed by PspRequestlotStateChange-CycleUp. 
When appropriate, the lOT volunteers lotStatelnfo- 
CycledUpPrinting-TasklnProcess and begins the sequence of 
imaging messages. Neither client layer imaging messages nor 
Page sync may appear at the interface until page-time is 
stabilized to the specifications of the lOT. The messages will 
precede page sync because of the scheduling offset, the 
necessity for Request to precede the page sync interval during 
which the image is delivered, and the restriction that page sync 
may be present only when the video for an actual image is being 
delivered. The imaging message sequence begins with the Hint, 
Print, and Request triplet for the first image, and continues with 
the triplets for the second and subsequent images. The first 
transition of page sync occurs in the page-time following the 
Request for the first image. Note that all Hint, Print, and Request 
messages must conform to the timing requirements given in 
figure 6-4, including those which precede the onset of page 
sync. The latter must be timed with reference to the lOT internal 
slow scan time base. The image generator must rely on the Hint 
preceding the first page sync transition as the timing reference 
for delivery of video for the first image. Subsequently, the image 
generator can use the previous page sync transition, which is a 
more accurate reference. The number of messages which occur 
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prior to page sync will depend on the scheduling offset. Figure 
6“7a shows the minimum. For example, refer to figure B6-7a in 
appendix B for a case with scheduling offset of 3. A similar 
sequence for scheduling offset = 1 and two copies to a 
bindexer output destination is shown in figure C6-7-a of 
appendix C. 


6,5-2 Cycle-down sequence 


Figure 6-7-b illustrates the simplex cycle-down sequence. It is 
assumed that the lOT has been cycled-up and printing. The last 
image to be printed from the current bank is image-n. It is 
assumed that the value of (n) was not known beforehand; 
therefore, cycle-down (End-of-job) is programmed with a 
PspNextBankRequest near the end of of the job. In figure 6-7-b, 
the PspNextBankRequest is shown occuring during the latest 
page-time permissible. This is followed by a Print dead cycle in 
the same page-time, and then a sequence of page times 
containing Request dead cycle, F^int dead cycle, and Print dead 
cycle. This sequence must continue at least one cycle beyond 
the page-time during which the last image is delivered, so that 
the final Hint, occurring during the first dead cycle, can provide a 
timing reference for re-imaging the last image, in the event that it 
is aborted. Note that the sequence would look slightly different 
if the PspNextBankRequest were issued during an earlier cycle. 
In that case, a Hint dead cycle would replace the Hint n + 1. 
When the scheduling offset is greater than one, there is a 
corresponding number of additional dead cycles. Refer to figure 
B6-7-b, appendix B. A similar sequence for scheduling offset = 
1 and two copies to a bindexer output destination is shown in 
figure C6-7-b of appendix C. 


6,5,3 Duplex cycle-up sequence 


A duplex cycle-up sequence is shown in figure 6-8. The 
sequence is initially the same as figure 6-7-a (the plate numbers 
indicating simplex side and duplex side are included in the 
illustration). The sequence continues with simplex side images 
for nine page times, corresponding to the assumed duplex paper 
path length, then alternates between duplex side and simplex 
side images. This is characteristic of duplex paper paths. 
However, some non-storing, or racetrack, duplex paper paths 
may require alternate dead cycles in the initial simplex sequence, 
so as to allow for subsequent interleaving of the simplex and 
duplex images. Recent racetrack designs do not require dead 
cycles. Note also that the DuplexOffset (refer to 
lotConfiguration) increases (from 9 to 17, in this example) as the 
duplex path is filled. This is characteristic of a storing duplex 
paper path. With a non-storing or racetrack duplex path, the 
DuplexOffset remains constant. A corresponding sequence for 
scheduling offset of 3 is shown in figure B6-8 of appendix B. A 
similar sequence for scheduling offset = 1, two copies to a 
bindexer output destination, and a racetrack duplex paper path 
with DuplexOffset = 8, is shown in figure C6-8 of appendix C. 


6.5.4 Duplex cycle-down sequence 


A duplex cycle-down sequence is shown in figure 6-9. The 
PspNextBankRequest for End-of-job at sheet 19 occurs during 
page sync for image 9,2, preceding Hint 19,1 and Print 19,1. The 
sequence, therefore, reverts to continuous duplex sides at the 
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next opportunity, i.e., during page sync for image 19,1, the lOT 
begins hinting for image 12,2 (to follow 11,2) rather than for 
20,1. After the last valid image (19,2) is requested, the lOT 
begins to hint dead cycles. When the duplex paper path is 
depleted, the sequence continues so as to provide the final Hint, 
as in figure 6-7-b. The corresponding sequence for scheduling 
offset of 3 is shown in figure B6-9, appendix B. A similar 
sequence for a scheduling offset = 1, two copies to a bindexer 
output destination, and a racetrack duplex paper path with 
DuplexOffset = 8, is shown in figure C6-9 of appendix C. 


6,5.5 Duplex-to-simplex transition 


Figure 6-10 illustrates a duplex to simplex transition. The 
sequence is similar to the duplex cycle-down case, except that 
after it depletes the duplex paper path with an ail duplex-side 
sequence, it continues with an all simplex-side sequence. 


6.5.6 Simplex abort sequence 


A simplex abort sequence is shown in figure 6-11. A 
PspSheetBankAbort of sheet 10 is assumed to occur during page¬ 
time for image 10. This image will, therefore, be discarded (this 
may result in a hole in the paper path, or in a discarded sheet 
bearing the damaged image, depending on when paper is 
committed in a particular lOT). Since image 11 has already been 
requested, it will be imaged and will also have to be discarded. 
The PspSheetBankAbort intervenes between Hint 12 and the 
expected Print 12. Hint 12 is, therefore, answered with Print- 
dead-cycle to allow the lOT to recover. Following the Request- 
dead-cycle response, the Hint, Print, Request sequence has 
recovered, and the imaging sequence recovers following the 
dead cycle. Note that page sync does not occur during the dead 
cycle, and the image generator in the PSP must rely on H1,1 for 
its timing reference for reimaging image 10. The corresponding 
sequence for scheduling offset of 3 is shown in figure B6-11 of 
appendix B. In this case three dead cycles are required to effect 
recovery. 

Note; The number of dead cycles required for recovery is 
dependent on the scheduling offset. It may also be job 
dependent and lOT dependent in other respects. The number 
shown is the minimum for the conditions assumed. 


6.5.7 Duplex abort sequence (simplex side) 

Figure 6-12 illustrates a duplex abort sequence in which the 
sheet abort occurs during imaging of simplex side 15. Note that 
duplex side imaging continues uninterrupted, while simplex side 
imaging recovers in an interleaved fashion. The aborted image is 
the only one lost, and only one dead cycle is required to 
recover. The corresponding sequence for scheduling offset of 3 
is shown in figure B6-12 of appendix B. In this case, two dead 
cycles are required to effect recovery (refer to note in section 
6.5.6). 

6.5.8 Duplex abort sequence (duplex side) 


Figure 6-13 illustrates a duplex abort sequence in which the 
sheet abort occurs during imaging of duplex side 4. In this case, 
recovery must start with simplex side 4. Therefore, the original 
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sheet 4 is lost, the next in sequence simplex image, 13, is lost 
(since it has already been requested and would now be out of 
sequence), and the duplex path is flushed of all its simplex 
imaged sheets (5 through 12). This is followed by an all simplex 
sequence which refills the duplex path with re-imaged simplex 
sides 4 through 12. Sheet 4 is now available to accept the 
originally aborted duplex side 4, and the normal simplex-duplex 
alternating sequence resumes. The corresponding sequence for 
scheduling offset of 3 is shown in figure B-6-13 of appendix B. 
In this case, recovery is achieved with the same number of dead 
cycles (refer to note in section 6.5.6). 

6.5,9 ASAP interrupt sequence (simplex jobs) 

Figure 6-14 illustrates an ASAP interrupt sequence in which a 
simplex job, JobNumber 7, is interrupted by a five-page simplex 
job, jobNumber 8 (for simplicity, PlateNumbers and 
CopyNumbers are omitted from the figure). In this case, the 
interrupt is initiated by a PspNextBankRequest following the Hint 
for SheetNumber 11, jobNumber 7, and designates the first 
sheet of the interrupting job as number 12. The lOT, however, is 
unable to effect the interrupt immediately, and does not begin to 
Hint SheetNumber 12, jobNumber 8 until SheetNumber 12, 
jobNumber 7 is being imaged. This results in reusing 
SheetNumbers 12 and 13 in the interrupting job, but the 
jobNumbers preclude ambiguity. The interrupting job is ended 
normally by means of a PspNextBankRequest specifying 
EndOfjob at SheetNumber 16, jobNumber 8. A 
PspNextBankRequest specifying Resumelnterruptedjob, 
jobNumber 7, causes the lOT to return to the job #7 parameter 
banks and resume Hinting with the SheetNumber next in 
sequence following the interrupt point. The lOT is responsible 
for chosing the actual interrupt point in the sheet sequence of 
jobNumber 7, and for saving the context and parameter banks of 
the interrupted job (also refer to section 6.4.6). 
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Figure 6-7-a. Simplex cycle-up sequence 

(scheduling offset = 1) 



NBR 


Rq Q :: s Request for a Dead Cycle (DC) 

Hn P„ R„ :: = n-th ’’Hint, Print, Request” triplet. (Only sheet nos. are shown.) 


Figure 6-7-b. Simplex cycle-down sequence 

(scheduling offset = 1) 



NBR 

End«of-|ob ^ Sh««t n 


H(jo :: s "Hint" Dead Cycle (DC) 

pQ Q s Print Dead Cycle 

Rq Q s Request tor a Dead Cycle 

Hp P„ R„ :: = n*th "Hint, Print, Request" triplet. (Only sheet nos. are shown.) 
NBR :: s NextBankRequest 
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Figure 6-8. Duplex cycle-up sequence 

(scheduling offset = 1) 

(Storing duplex paper path, minimum duplex offset 
= 9) 
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H, I P, j R, j s "Hint, Print, Request" triplet for sheet i, plate j. 
j :: s PlateNumber 

PiateNumber = simplex side | duplex side 

simplex side :: s 1 
duplex side :: = 2 
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Figure 6-9. Duplex cycle-down sequ 

(scheduling offset = 1) 
(Storing duplex paper patl 
= 9) 
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"Hint, Print, Request” triplet for sheet i, plate j. 
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Figure 6-11. Simplex abort sequence 

(scheduling offset = 1) 
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Ho,o * "Hint" Dead Cycle (DC) 

Pqq :: s Print Dead Cycle 

Rg g :: s Request for a Dead Cycle 
H„ P„R„ :: = n*th "Hint, Print, Request" triplet. 
SBA ::s SheetBankAbort 
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Figure 6-12. Duplex abort sequence, 

sheet abort during simplex side imaging 

(scheduling offset = 1) 

(Storing duplex paper path, minimum duplex offset 
= 9) 


^4,2 ^13,1 

T Y 

^13,1*^S,2 

Y Y 

r—^ 

*^S,2*^14,1 ^ 

Y Y 

j SCHEDULII 
14,1*^ 8,2 

Y Y 

iG OFFSET « 1 

^6,2** 15,1 

Y Y 

*^15,1**7,2 

Y Y 


12,1 

Image 4,2 | 

X X 

Image 13,1 

X 

1 Image 5,2 

Image 14,1 

X 

Image 6,2 

X 

“L 

X 

Pag# Sync 

^13,1 ^5,2 ^14.1 


P5,2 

Pl5.1 

^r,2 

^7,2^16,1 

^0,0 ^8,2 

^8,2*^15,1 ^ 

15,1*^9,2 

P9,2**16,1 

*^16,1*^10,2 


T T 

Y Y 

T Y 

Y Y 

Y Y 

Y Y 


I Image 15,1 

j [image 7.2 I 

DC 

- -1- -- 

Image 8,2 

Image 15,1 

Image 9,2 


1 

X X 

X 


X 

X 

1 

T 

^0,0 ^8,2 ^15,1 


^9,2 

Pl8,1 

Pl0,2 

SBA 







Sheet #15 






^10,2^17,1 

^17,1^11,2 

^11,2*^18,1 

18,1*^12,2 

*^12,2*^19,1 

*^19,1*^13,2 


T T 

Y Y 

Y Y 

Y Y 

Y Y 

Y Y 


Image 16,1 

Image 10,2 j 

Image 17,1 

Image 11,2 

Ima 9 e 18,1 

Image 12,2 

“L 


X X 

X 


X 

X 

X 


^17,1 ^11,2 ^18,1 


Pl2,2 

Pl9.1 

Pi 3,2 

^13,2*^20,1 

^20,1*^14,2 

*^14,2*^21,1 

21,1*^15,2 

*^15,2*^22,1 

*^22,1*^16,2 


T T 

Y Y 

Y Y 

Y Y 

Y Y 

Y Y 


Image 19,1 

Image 1 3,2 | 

Image 20,1 

Image 14,2 

Image 21,1 

Image 15,2 

T. 


X X 

X 


X 

X 

X 


^20,1 ^14,2 ^21,1 


Pl5,2 

^22,1 

Pl6,2 


H, j P, I R, j :: s "Hint, Pnnt, Request” triplet for sheet i, plate j. 
j :: s PlateNumber 

PlateNumber simplex side | duplex side 

simplex side ;:s 1 
duplex side :: s 2 

SBA :: s SheetBankAbort 
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Figure 6-13. Duplex abort sequence, 

sheet abort during duplex side imaging 

(scheduling offset = 1) 

(Storing duplex paper path, minimum duplex offset 




= 9) 
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H, j P, j R, j :: s "Hint, Print, Request” triplet for sheet i, plate j. 
j ::s PlateNumber 

PlateNumber ::s simplex side | duplex side 

simplex side :: s 1 
duplex side :: s 2 

SBA :: s SheetBankAbort 
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Figure 6-14. ASAP interrupt^ simplex jobs 

(Job #7 interrupted by a 5 page job, #8.) 
(scheduling offset = 1) 
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H, i P, j R, j :: s "Hint, Print, Request" triplet for sheet i, job j 
(PlateNumber and CopyNumber not shown) 
NBR s NextBankRequest 
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6.6 lOT diagnostic protocol 


No distinct diagnostic machine state or substate is prescribed 
herein. The diagnostic state may be considered to be a superset 
of the prescribed machine states and substates, i.e., diagnostics 
may be initiated in any machine state and substate. 

There are two types of diagnostic utilities, active and passive. An 
active diagnostic utility renders the lOT unavailable for customer 
jobs in either the cycled-up or cycled-down machine state, and 
the accompanying Productivity substate must be Service. For 
example, an Active diagnostic utility may comprise one or more 
preprogrammed printing jobs. A passive diagnostic utility is a 
measuring or monitoring activity which can run concurrently with 
a printing job if necessary, without interrupting the job. If the 
Productivity substate is Productive, it may remain Productive. 
However, the lOT must report such passive diagnostic activity via 
the InfoMessage field of lotOperationalInfo, since no machine 
state or substate change occurs. 

Diagnostic utilities are invoked by PspRequestlotDiagnostic. This 
command can be valid in any machine state. If the specific utility 
cannot be run because of priority activity in the lOT, the request 
must be denied via the Reject code in the Status field of 
lotDiagnosticResponse. A customer job, for example, must be 
considered priority activity. There may be other lOT-specific 
priority activities. The lOT indicates acceptance of 
PspRequestlotDiagnostic by echoing the contents of the 
Command field in the Status field of lotDiagnosticResponse. A 
sample diagnostic message exchange is illustrated in figure 6-15. 


6.7 lOT configuration data 


A great deal of lOT-specific information is conveyed to the PSP 
at start of operations, via the Status message, lotConfiguration. 
However, there remains some lOT-specific information which 
must be made known to the PSP by means other than this 
Generic Specification, or other than through operational 
exchange of Command/Status messages. This information is 
listed below: 

1. Internal grounding arrangements: The connection 

arrangements between signal ground and ground mecca 
within the lOT must be coordinated with the similar 
arrangements within the PSP, so as to achieve the desired 
noise and EME performance of the overall printer formed by 
interconnecting the particular PSP and the particular lOT with 
the cable prescribed herein (section 8.9). 

2. Coding of lOTMetaReset, coarse codes and fine codes 
(section 6.3.3). 

3. Coding of lOT display message numbers, to be used in 
PspRequestlotAction command (section 6.3.2). 

4. Fault codes and message codes, to be used in 

lotOperationalInfo, for TechRepCIearOnlyFaults, 

OperatorClearFaults, TechRepReTryFaults, HintMessage, and 
InfoMessage. Configuration type for lotConfiguration, fault 
numbers for TechRepReTryfaults (section 6.3.3). 
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5. Coding of ConfigurationlD, to be used in status message, 
lotConfiguration (section 6.3.3). 

6. Diagnostic Utility and Utility Parameter descriptions and 
identification, to be used in Command/Status messages, 
PspRequestlotDiagnostic and lotDiagnosticResponse 
(sections 6.3.2 and 6.3.3). 

7. Diagnostic Utility software, which must be down loaded by 
the PSP to the lOT prior to running lOT diagnostics, unless 
this software is lOT resident. 


6.8 PSP configuration data 


There is no information about the PSP which must be made 
known to the lOT, beyond that which is prescribed in this 
Generic Specification or made known in the prescribed 
Command/Status message exchanges, except for the internal 
grounding arrangements implied in section 6.7.1. 
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Figure 6-15. Sample diagnostic message exchange 


PSP 



lOT 

PspRequestiotDiagnostic 

Utility (Corotron Chock) 
ParamotorlO (Charging Currant) 
ParamotorValua (Null) 

Command (Entar) 



lotOiagnosticResponse 



Utility (Corotron Chock) 
ParamotorlO (Charging Currant) 
ParamotorValua (Null) 

Status (Entar) 

PspRequestlotOiagnostic 

Utility (Corotron Chock) 
ParamotorlO (Charging Currant) 
ParamotorValua (Null) 

Command (Road) 



lotOiagnosticResponse 



utility (Corotron Chock) 
ParamotorlO (Charging Currant) 
ParamotorValua (100 ua) 

Status (Road) 

PspRequestiotDiagnostic 

Utility (Corotron Chock) 
ParamotorlO (Charging Currant) 
ParamotorValua (Null) 

Command (Exit) 


— _ 

lotOiagnosticResponse 


Utility (Corotron Chock) 
ParamotorlO (Charging Currant) 
ParamotorValua (Null) 


Status (Exit) 


t 

TIME 
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Video data signal quality 


7.1 Transmission impairments 


Transmission across the interface will subject video data and 
clock signals to propagation delay, to intersymbol interference, 
and to attenuation. Delay and intersymbol interference are 
caused by the active interface components, as well as by the 
cable. Attenuation is due only to the cable. Delay itself is not 
considered to be an impairment, but variations in absolute delay 
of the data relative to the clock can affect the ability to reclock 
the data without error. Cain in the line receiver compensates for 
attenuation, but if the loss of noise margin at the receiver input is 
severe, the amplified signal may contain errors caused by noise. 

Intersymbol interference is caused by the spreading of the 
energy allocated to a bit interval into adjacent bit intervals. In 
general, the interference can spread over several bit intervals and 
can precede as well as trail the reference Interval. With the 
recommended interface (chapter 8), the interference Is almost all 
trailing. The interference Is non-stationary, I.e., observable as 
time jitter when the data is non-stationary, i.e., non-repetitive. 
The interference is stationary with repetitive signals, such as a 
clock, and does not cause observable displacement of the clock 
transitions relative to each other. However, displacements can 
occur between clock transitions at the beginning or end of clock 
bursts, relative to transitions away from these extremes. When 
the strings of zeroes in the data, and the quiescent intervals of 
clock, both exceed the range of the intersymbol interference, the 
relative displacement of clock transitions is of the same order of 
magnitude as the jitter observed on the data. This is the case for 
the prescribed interface. Therefore, for purposes of analysis, the 
same amount of jitter will be assigned to both pixel clock and 
video data. 

jitter is quantified as the difference between the worst-case 
transition displacement in the negative time direction and the 
worst-case transition displacement in the positive time direction 
(i.e., peak-to-peak relative to the nominal position of the 
transition), and is stated as a percentage of the nominal pixel 
interval. These measurement relationships are shown in the 
stylized sketch in figure 7-1. The standard interface has been 
designed to provide less than 5 percent jitter at the output of the 
line receivers at 25 Megabits per second. 

Cable attenuation results in loss of noise margin at the receiving 
end of the cable. The differential noise margin is defined as the 
difference between the magnitude of the differential signal at the 
line receiver input, and the minimum allowable differential input. 
The acceptable limits for ECL output logic levels are VOHAmin 
and VOLAmax. Thus, the minimum acceptable differential output 
is as follows: 

[VOHAmin - VOLAmax] = [-0.98v - (-1.63v)] = 650 mv. The 
minimum allowable differential input Is taken to be 200 mv. 
Therefore, the differential noise margin available for attribution to 
the cable is 450 mv. Measurements have shown that cable 
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attenuation will be somewhat less than 3 db at 25 Mbps with 50 
feet of cable. Again, assuming minimum ECL output of 650 mv 
from the line driver, the minimum differential signal arriving at the 
input to the line receiver with 3 db of attenuation would be 460 
mv, and the realized differential noise margin would be 460- 
200= 260 mv. (The normal ECL logic noise margins are 125 mv 
and 155 mv for the high and low logic levels, respectively.) Of 
course, the signal will also enjoy the common mode rejection of 
the recommended line receiver, H-1 volt. In view of the above, 
cable attenuation is not considered to be a problem. 

Figure 7-1. Definition of video data jitter 



% JITTER . 


JITTER INTERVAL 
NOMINAL BIT INTERVAL 


X 100 


7.2 Timing analysis for reclocked modes 


An example of the overall timing relationships for the reclocked 
modes is shown at the top of figure 7-2. The propagation delay 
due to the cable and components will cause a slight image shift 
in the fast scan direction, but this shift will be compensated by 
the image alignment process. Only signal degradations which 
cause reclocking errors will affect the quality of the video data 
delivered to the marking engine. The principle concern, 
therefore, is the reliability of reclocking, or more specifically, the 
phase relationship between video data and return clock, at the 
reclocking stage in the lOT interface. The analysis presented 
below applies equally to reclocking in the serial or parallel video 
data transmission mode, since worst case conditions will be 
considered. 

It Is assumed (but not required) that the proper phase 
relationship between video data and return (pixel or byte) 
clock is established at the PSP by generating the return clock as 
the inverse of the clock received from the lOT. This establishes 
the rising edge of the return clock nominally at the center of the 
video data interval. The steady state phase relationship between 
video data and return clock as received at the lOT, thus, depends 
on the duty cycle symmetry of the (pixel or byte) clock, plus the 
propagation delay tolerances of all the active and passive circuit 
elements in each transmission channel between the clocking 
point in the PSP and the reclocking point in the lOT. The 
transient phase relationship between video data and return clock 
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as received at the lOT depends on the jitter characteristics of ail 
the active and passive circuit elements in each transmission 
channel between the clocking point in the PSP and the 
reclocking point in the lOT. It is assumed that the transient 
displacements will add to the steady state displacements in the 
worst combinations. The model for the following timing 
tolerance analysis is shown at the bottom of figure 7-2. It is 
based on the circuits recommended in chapter 8. 

Taking the clock at point C in figure 7-2 as the absolute timing 
reference, the video data is subjected to the propagation delays 
of the ECL clocking stage, the cable, and the ECL line receiver 
before it arrives at point F, the input to the ECL reclocking stage 
in the lOT. The return clock is subjected to the propagation 
delays of the ECL line driver (which also effects logical inversion), 
the cable, and the ECL line receiver before arriving at point C, 
the other input to the ECL reclocking stage. In addition to delay, 
jitter can cause video data and clock transition displacements of 
±2.5 percent. The ECL flip-flop recommended for clocking has 
a propagation delay range of 1.5 to 3.7 ns. For the 
recommended drivers and receivers, the range of propagation 
delay is 1.0 to 2.8 ns. (These figures are based on the 
assumption that all the components in the PSP are at the same 
temperature (±85 degrees C) and all the components in the lOT 
are at the same temperature (±85 degrees C). The individual 
circuit functions, however, are not assumed to be on the same 
substrate.) The maximum difference in delay between any two 
pairs of the recommended cable is specified as 2 percent of the 
total delay. This includes differences in velocity of propagation, 
as well as differences in equivalent length. The nominal velocity 
of propagation, Vp, is 78 percent. The nominal propagation delay 
in nanoseconds per foot of cable is 1.017/Vp = 1.30 ns/ft. 
Consider a - 20 percent deviation from nominal for vp. The 
worst case differential delay between two pairs of a fifty foot 
cable is then (1.30 x 1.2) ns/ft x .02 x 50 ft. = 1.56 ns. (In the 
analysis, this difference is split between the signals, 0.78 ns 
relative advance and 0.78 ns relative delay.) The clock phasing 
tolerance is specified as ±5 percent in sections 4.2.1 and 4.2.2. 
In this analysis, it is assumed to be due to inverting a received 
clock with ±5 percent duty cycle tolerance. 

With the above parameters, and assuming 25 Mhz clock and 25 
Megabits per second data on any given video data path, the 
earliest clock at point G in figure 7-2 will be delayed 1.0 ns each 
by the line driver and receiver, and advanced 0.78 ns by the 
cable, and 2.0 ns by -5 percent initial phasing error and 1.0 ns 
by -2.5 percent jitter, for a relative advance of 1.78 ns. The 
latest clock will be delayed 2.8 ns each by the line driver and 
receiver, 0.78 ns by the cable, 2.0 ns by ±5 percent initial 
phasing error, and 1.0 ns by ±2.5 percent jitter, for a relative 
delay of 9.38 ns. The earliest data at point F in figure 7.2 will be 
delayed 1.5 ns by the clocking stage in the PSP, 1.0 ns by the 
line receiver, and advanced 0.78 ns by the cable, and 1.0 ns by 
-2.5 percent jitter, for a relative delay of 0.72 ns. The latest 
data will be delayed 3.7 ns by the clocking stage in the PSP, 2.8 
ns by the line receiver, 0.78 ns by the cable, and 1.0 ns by ±2.5 
percent jitter, for a relative delay of 8.28 ns. 

These figures are summarized in figure 7-3, which shows that at 
25 Megabits per second and with 50 feet of cable, there is a 
margin of 9.94 ns between earliest clock and latest data, and a 
margin of 11.34 ns between latest clock and earliest data. These 
margins are adequate for reliable reclocking, provided that the 
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first stage of reclocking following the cable receivers is 
implemented with ECL components. 

If TTL were to be used for the clocking and reclocking stages, 
TTL/ECL and ECL/TTL translators would have to be used for the 
line drivers and receivers, respectively, and an extra translator 
would be needed at the output of the clocking stage in the PSP. 
The set-up time for TTL reclocking would be somewhat longer 
than for ECL, and the translators have a wider range of 
propagation delay than the ECL devices. A careful analysis 
should be carried out for any TTL design. It is estimated that the 
maximum data rate would be around 12.5 Megabits per second. 
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Figure 7-2. Overall timing relationships for reclocked video 
data modes 

(Assuming 25 Mbps, and 50 ft of cable @ 1.3ns/ft) 
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Figure 7-3. Timing tolerance analysis for reclocked video 
data modes 
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PARAMETER 

VALUE 

EARLIEST 

DATA 

LATEST 

DATA 

EARLIEST 
CLOCK _ 

LATEST 

DATA RATE 

25 MBPS (40 no) 





CABLE LENGTH 

50 ft 





VP 

78% 





LINE DRIVER tp RANGE 

1.0 to 2.8 no 



♦ 1.0 

♦ 2.8 

LINE RCVR tp RANGE 

1.0 to 2.8 nt 

♦ 1.0 

♦ 2.8 

♦ 1.0 

♦ 2.8 

CABLE DELAY TOLERANCE 

♦ /-O.TS nt (♦ /.1%, 2% total) 

•0.78 

♦ 0,78 

-0.78 

♦ 0,78 

PSP CLOCKING STAGE tp RANGE 

1.5 to 3.7 nt 

♦ 1.5 

♦ 3.7 



CLOCK DUTY CYCLE TOLERANCE 

♦ /•2.0nt(o/-5%) 



•2.0 

♦ 2.0 

DATA JITTER 

♦ /-I.O nt (♦ /•2.5%y 5% p-p) 

•1,0 

♦ 1,0 



CLOCK JITTER 

♦ 1.0 nt(#2.5%) 



•1.0 

♦ 1.0 


TOTAL 

♦ 0.72 

♦ 8.28 

•1.78 

♦ 9.38 
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Electrical characteristics 
of interface circuits 


8.1 Line drivers 

All line drivers shall be MECL 10K Series with both nornnal 
and inverted outputs for differential driving. The 
recommended components are gate MC10212 (Xerox Part 
No. 733W01732), line receiver MC10216 (XPN 733W02917) 
used as a line driver, flip-flop MC10231 (XPN 733W01734), 
and TTL/ECL translator MC10124 (XPN 733W01682). The 
generic circuit for line drivers is shown in figure 8-1. Other 
MECL 10K Series components with differential output may be 
used if different logic functionality is desired at the input, or 
if different functional modularity is desired. A timing analysis 
should be performed, however, if slower devices are 
substituted in the video or return clock circuits of the 
recommended interface implementation (refer to section 
8.3). 


8.2 Line receivers 

All line receivers shall be MECL 10K Series with differential 
inputs. The recommended components are MC10216 (XPN 
733W02917) and ECLTTTL translator MC10125 (XPN 
733W01685). The generic circuit for line receivers is shown 
in figure 8-2. Other MECL 10K Series components with 
differential input may be used if different logic functionality is 
desired at the output, or if different functional modularity is 
desired. A timing analysis should be performed, however, if 
slower devices are substituted in the video or return clock 
circuits of the recommended interface implementation (refer 
to section 8.3). 


8.3 Recommended circuit implementation 

Circuits recommended for implementation of the PSP 

Imaging Interface and Command/Status Interface are shown 
in figures 8-3-A and 8-3-B. These circuits provide return byte 
(or pixel) clock, and accommodate both parallel and serial 
video data transmission modes. If only the serial mode is to 
be implemented, lOTclkECL-b is not needed, and only one 
flip-flop stage need be implemented. These circuits are the 
basis for the PSP side of the timing analysis model in section 
7.2. 

Circuits recommended for implementation of the lOT 

Imaging Interface and Command/Status Interface are shown 
in figures 8-4-A and 8-4-B. These circuits provide for use of 
return byte (or pixel) clock, and accommodate both parallel 
and serial video data transmission modes. For the serial 
video data mode, only one video data channel need be 
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implemented, and RetClkECL-b is not needed. If the serial 
data is not to be reclocked in the lOT, the return pixel clock 
channel (below the dashed line in figure 8-4-A) need not be 
implemented. These circuits are the basis for the lOT side of 
the timing analysis model in section 7.2. 

Note that the output of balanced line receivers may or may 
not be predictable under conditions of open input (cable 
disconnected) or signal source power off (consult device 
specifications). It is recommended that the output of line 
receivers be inhibited or ignored at a higher system level 
when such conditions exist. Circuits for detecting these 
conditions are discussed in section 8,5. 


8.4 Power control 


The required power control arrangement* isr shown in figure 8-5. 
A T-12VDC power source in the PSP is connected to a low- 
power control actuator in the lOT via the power control + line 
in the interface cable. The control actuator, In turn, operates a 
power actuator which switches the AC mains in the lOT. The 
return circuit is via the power control - line in the interface 
cable and the control circuitry in the PSP. Resistor R4 limits the 
current which can be drawn from the +12VDC power source. 
The control actuator is not specified, but is nominally a 6V, 120 
ohm device. Resistor R5 is selectable to allow a choice for the 
control actuator. It is considered to be part of the load in the 

lOT. The design of this power control arrangement, the 

recommended control circuitry for the PSP, and an example 
selection of R5 are discussed in appendix D. The power source 
must be capable of supplying at least 65 ma operationally. 
Resistance R4 must have an effective power rating sufficient to 
withstand a short circuit to ground of the power control + line, 
without damage to itself or to the printed wire board. The 

power source must be able to supply worst case short circuit 

current of 150 ma (5 percent high voltage, 9 percent low R4). 

The PSP Power Normal input to the control circuitry must detect 
AC power line failures greater than 10 milliseconds, and must 
drop power control to the off condition within 50 milliseconds 
and hold it off for at least 2 milliseconds. The control actuator 
device in the lOT, and the control circuitry in the PSP, must be 
protected from transients as large as 20V and as long as 1 
microsecond on the power control lines (a filtering scheme for 
this purpose is shown in appendix D). The control actuator 
device in the lOT must also be safety isolated from the AC 
power source to at least 1600 VAC. It is expected that the Vcc 
power supplies in the PSP and the lOT will continue to supply 
regulated output for 5 milliseconds after AC power has been 
removed from their input by a power failure or by switching. 

The control circuitry in the PSP must be glitch-free during power 
turn-on and turn-off. That is, until the Power Normal signal and 
the Power On signal are both at the high-level state, (> 2.4 v), 
the control output device shall be an open circuit. It is also 
recommended that the origin of the Power On signal be 
protected by use of encoded turn-on and turn-off signals, rather 
than simple binary state changes. 

Whenever a non-emergency lOT power-down is initiated via the 
control element in the PSP, the PSP must send an advanced 
warning to the lOT via Client Layer message, PspMetaReset. The 
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amount of time required for the advanced warning is an lOT 
parameter, which must be conveyed to the associated PSP as the 
PowerDownWarning parameter of the Client Layer message, 
lotConfiguration. If the time is less than 5 milliseconds, no 
warning message need be sent. The default time is zero. 

Results of activating or deactivating the Power On signal may be 
monitored in the PSP by means of the detection circuit discussed 
In section 8.5. 


8.5 Detection of cable and power status at the interface 


Certain interface conditions can be detected at the line receivers, 
namely, power on/off at the opposite side of the interface, 
and.^or the interface cable disconnected. Figure 8.6 shows a 
simple addition to the line receiver circuit to accomplish this. 

In figure 8-6, the upper part of the diagram is the normal cable 
termination and line receiver circuit (see, for example, figure 8-3- 
A). When the signal source Is powered and connected, the 
voltage at point A in the diagram will be at the midpoint of the 
ECL signal range, i.e., about -1.29 vdc. This will be true 
whether or not the signal is active, and for either quiescent logic 
state. Each MC125 detector is biased by the voltage divider, 
relative to point A, so that its output is logic low. If the cable is 
disconnected, point A goes to approximately -5.2 vdc. This 
biases the upper detector further off, but biases the lower 
detector so that its output is at the high logic level. If the cable 
is connected but the power on the other side of the interface is 
off, the signal source becomes a low impedance to ground, and 
point A goes to near ground. This biases the lower detector 
further off, but biases the upper detector so that its output is at 
the high logic level. 

These circuits are optional in the PSP for monitoring the normal 
lOT power on/off state, and also to provide low-level interface 
diagnostics. It is recommended that, if used, they be 
implemented on the status line receiver. They may also be used 
in the lOT for diagnostic purposes. In the lOT, they should be 
implemented on the command line receiver. The cable- 
disconnected detector may also be used to accomplish hardware 
or software override of any line receiver output which causes a 
problem when the PSP or lOT must retain some level of 
functionality when disconnected at this interface. 

Either or both of the detectors can be implemented, as desired, 
and they may be implemented on one or more of the line 
receivers. Theoretically, they do not affect the performance of 
the signal path. It is recommended, however, that they not be 
applied to a high-speed signal path without verifying the 
performance. 


8.6 Interface power supplies 


The dc power sources semng the interface ECL circuits in the 
PSP and in the lOT shall be -5.2 vdc ±5 percent. The power 
supply common in each unit shall be signal ground for the 
interface circuits and shall be connected to the common logic 
ground within the respective units. 
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8.7 Cables 


When the generic interface is implemented for serial video data 
transmission, the 9-pair cable specified by Xerox Drawing No. 
117P23905 shall be used. When the generic interface is 
implemented for parallel video data transmission, the 16-pair 
cable specified by Xerox Drawing No. 117P23904 shall be used. 
These drawings define cables composed of individually-shielded 
twisted pairs, each with nominal characteristic impedance (Zo) of 
100 ohms, and nominal velocity of propagation (Vp) of 0.78c. All 
of the shielded pairs are enclosed within a single overall shield. 
Each signal of the generic interface shall be carried on one pair of 
the cable. Each cable provides one spare shielded twisted pair. 
The complete electrical and mechanical specifications are 
contained in the drawings. 


8.8 Connectors 


When the generic interface is implemented for serial video data 
transmission, connectors, receptacles, and auxilliary hardware 
from the 37-pin D-Shell series shall be used. When the generic 
interface is implemented for parallel video data transmission, 
connectors, receptacles, and auxiliary hardware from the 50-pin 
D-Shell series shall be used (part numbers are given in chapter 9). 


8.9 Shielding and grounding (refer to figure 8-7) 


Within the PSP and within the lOT, the cable shields shall be 
connected as follows: 

a) The outer shield of the interface cable shall be connected to 
a ground "mecca" that is a common point for frame ground 
and green wire ground of the AC power source. Connection 
is to be via both pin 1 and the connector shell. It is 
desirable that the outer shield ground circuit be completed 
before any other circuit is completed, when the cable is 
installed. 

b) The shield circuit of each twisted pair shall be connected to 
signal ground (logic ground). 

c) Provision must be made for connecting signal ground to the 
ground mecca within the PSP and within the lOT; however, 
the nature (impedance) of the connection, including no 
connection, is to be determined by the product program. 

d) The common side of the - 5.2v power supply serving the 
interface drivers and receivers must be tied to signal ground 
within each unit. 

The length of the balanced signal-runs inboard of the interface 
connector should be minimized. Etch runs should be in the form 
of differential microstrip or differential stripline, with characteristic 
impedance of 100 ohms to match the characteristic impedance 
of the shielded twisted pairs. The specific physical arrangements 
for cable routing and grounding within the PSP and lOT are the 
responsibility of the respective product programs. 
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Figure 8-1. Generic circuit for line drivers 
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Figure 8-2. Generic circuit for line receivers 
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TTLCommand 


Figure 8-3-A. Circuits recommended for implementation of 
PSP imaging interface and Command/Status 
interface. Both parallel and serial video data 
modes are provided. 
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Figure 8-3-B. Circuits recommended for implementation of 
PSP video data interface. Both parallel and serial 
video data modes are provided. 
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Figure 8-4-A. Circuits recommended for implementation of 
lOT imaging interface and Command/Status 
interface. Both parallel and serial video data 
modes are provided. 
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Figure 8-4-B. Circuits recommended for implementation of 
lOT video data interface, parallel mode. (Only 
circuits associated with Video Data 7 are 
implemented for Serial Reclocked Mode.) 
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Figure 8-5. Power control interface 

(also refer to figure D-1, appendix D.) 
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Figure 8-6. Circuits for detection of cable and power status 
at the interface 
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Figure 8-7. Generic grounding arrangements 
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Mechanical characteristics 

of interface 


The hardware recommended below is the most appropriate 
currently available. Various product programs are working to 
develop compatible improvements (for example, less bulky, 
molded, better shielding). As these become available, they will 
be added to this generic specification. 


9.1 Demarcation points (refer to figures 8-6 and 9-2) 


The PSP interface with the lOT Is defined to be at the mating 
point of the 37-pin (or 50-pin) receptacle mounted in the PSP, 
with the matching plug mounted on the interface cable. The 
receptacle in the PSP must be mounted on a backpanel (or 
equivalent), with no more than one PWB edge connector 
between this receptacle and the active components of the 
Imaging Interface circuits. 

The lOT interface with the PSP is defined to be at the mating 
point of the 37-pin (or 50-pin) receptacle mounted in the lOT, 
with the matching plug mounted on the interface cable. The 
receptacle in the lOT must be mounted on a backpanel (or 
equivalent) with no more than one PWB edge connector 
between this receptacle and the active components of the 
Imaging Interface circuits. The shield of this receptacle must be 
connected to the lOT ground "mecca" via its mounting 
hardware. 


9.2 Connectors 


9.2.1 37-pm D-Shell 


The following connectors and accessory parts from the 37-pin D- 
Shell series shall be used, as appropriate, in the PSP, the lOT, and 
the interconnecting cable assembly, when the generic interface is 
implemented for serial video data transmission with the 9-pair 
cable described in section 8.4. 
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Description 

Xerox Drawing No. 

Plug (for cable assembly) 

713W02637 

Contact (male, for plug) 

713W00937 

Shell (for plug) 

118P20514 

Outer Ferrule (for shell- 
cable assembly) 

115P00638 

Inner Ferrule (for shell- 
cable assembly) 

115P00669 

Receptacle (vertical PWB 
mount, pre-pinned, female, 
pressfit) 

713W20237 

Screw-lock (for PWB mount 
receptacle) 

713W81237 

Receptacle (bulkhead- 
mount) 

713W02737 

Contact (female, for 
bulkhead-mount receptacle) 

713W01037 

Screw-lock (for bulkhead- 
mount receptacle) 

713W80737 


9.2.2 50-pin D-Shell 


The following connectors and accessory parts from the 50-pin D- 
Shell series shall be used, as appropriate, in the PSP, the lOT, and 
the interconnecting cable assembly when the generic interface is 
implemented for parallel video data transmission with the 16-pair 
cable described in section 8.7. This connector will also be used 
in other special applications (refer to sections 9.2.4 and 9.3). 


Description 

Plug (for cable assembly) 

Contact (male, for plug) 

Shell (for plug) 

Outer Ferrule (for shell- 
cable assembly) 

Inner Ferrule (for shell- 
cable assembly) 

Inner Ferrule (for shell- 
cable assembly with 9-pair 
cable) 


Xerox Drawing No. 

713W02837 

713W00937 

118P20520 

115P00639 

115P00672 

115P00673 


Receptacle (vertical PWB 713W20337 

mount, pre-pinned, female, 

pressfit) 

Screw-lock (for PWB mount 713W81237 

receptacle) 

Receptacle (bulkhead- 713W02937 

mount) 
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Description 

Contact (female, for 
bulkhead-mount receptacle) 

Screw-lock (for bulkhead- 
mount receptacle) 


Xerox Drawing No. 

713W01037 

713W80737 


9,2.3 Pin orientation 


The physical layout of the pins in the 37-pin and 50-pin 
connector series is shown in figure 9-1. 

Figure 9-1. Connector pin orientations 

(viewing face of plug) 



37-PIN SERIES 



50-PIN SERIES 


9,2,4 Pin assignments 

a) 37-pin, Serial Video Mode: 


Pin No. 

1 

Signal 

Frame Ground 

Pin No. 

Signal 

0 

Power Control + 

20 

Power Control - 

3 

Signal Ground 

21 

Signal Ground 

4 

Spare + 

22 

Spare - 

5 

Signal Ground 

23 

Signal Ground 

6 

Command + 

24 

Gommand - 

7 

Signal Ground 

25 

Signal Ground 

8 

Status + 

26 

Status - 

9 

Signal Ground 

27 

Signal Ground 

10 

Page Sync + 

28 

Page Sync - 

11 

Signal Ground 

29 

Signal Ground 

12 

Line Sync + 

30 

Line Sync - 

13 

Signal Ground 

31 

Signal Ground 

14 

Pixel Clock + 

32 

Pixel Glock - 

15 

Signal Ground 

33 

Signal Ground 
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Pin No. 

Signal 

Pin No. 

Signal 

16 

Return Pixel Clock 4- 

34 

Return Pixel Clock 

17 

Signal Ground 

35 

Signal Ground 

18 

Video Data 4- 

36 

Video Data - 

19 

Signal Ground 

37 

Signal Ground 


b) 50-pin, Parallel Video Mode: 

(Also serves Serial Mode in universal PSPs with Video Data 0 through 6 not used.) 


Pin No. 

Signal 

Pin No. 

Signal 

Pin No. 

Signal 

1 

Frame Ground 





2 

Power Control + 

18 

Signal Ground 

34 

Spare 4- 

3 

Power Control - 

19 

Signal Ground 

35 

Spare - 

4 

Command 4- 

20 

Signal Ground 

36 

Status 4- 

5 

Command - 

21 

Signal Ground 

37 

Status - 

6 

Byte Clock 4- 

22 

Signal Ground 

38 

Line Sync 4- 

7 

Byte Clock - 

23 

Signal Ground 

39 

Line Sync - 

8 

Page Sync 4- 

24 

Signal Ground 

40 

Return Byte Clock 4- 

9 

Page Sync - 

25 

Signal Ground 

41 

Return Byte Clock - 

10 

Video Data 1 + 

26 

Signal Ground 

42 

Video Data 0 4- 

11 

Video Data 1 -■ 

27 

Signal Ground 

43 

Video Data 0 - 

12 

Video Data 3 4- 

28 

Signal Ground 

44 

Video Data 2 + 

13 

Video Data 3 -- 

29 

Signal Ground 

45 

Video Data 2 - 

14 

Video Data 5 + 

30 

Signal Ground 

46 

Video Data 4 4- 

15 

Video Data 5 - 

31 

Signal Ground 

47 

Video Data 4 - 

16 

Video Data 7 4- 

32 

Signal Ground 

48 

Video Data 6 4- 

17 

Video Data 7 - 

33 

Signal Ground 

49 

Video Data 6 - 





50 



9.3 Cable assemblies 


The product programs must design and issue cable assemblies 
according to their requirements, using the plugs, shells, and 
auxiliary parts prescribed in section 9.2, together with 9-pair 
cable, Xerox Part No. 117P23905, or 16-pair cable, Xerox Part No. 
117P23904 (also refer to section 8.7), and using the following 
guidelines. 


9.3.1 Cable assembly types 


There are three basic cable assemblies: 

Type-A 37-pin plug on each end of 9-pair cable (both PSP and lOT 
designed for serial video data). 

Type-B 50-pin plug on each end of 16-pair cable (both PSP and lOT 
designed for parallel video data). 
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MECHANICAL CHARACTERISTICS OF INTERFACE 


Type-C 50-pin plug on PSP end, 37-pin plug on lOT end of 9-pair cable 
(PSP designed for parallel video data, and lOT designed for serial 
video data). 

9.3.2 Pin assignments 

a) Type-A cable assemblies shall use the following pin assignments for each 37-pin 
plug: 


Pin No. 

Signal 

Pin No. 

Signal 

1 

Overall shield^ 



2 

Power Control + 

20 

Power Control - 

3 

Power Control Shield 

21 


4 

Spare + 

22 

Spare - 

5 


23 

Spare Shield 

6 

Command + 

24 

Command - 

7 

Command Shield 

25 


8 

Status + 

26 

Status - 

9 


27 

Status Shield 

10 

Page Sync + 

28 

Page Sync - 

11 

Page Sync Shield 

29 


12 

Line Sync -P 

30 

Line Sync - 

13 


31 

Lin^ Sync Shield 

14 

Pixel Clock -f 

32 

Pixel Clock - 

15 

Pixel Clock Shield 

33 


16 

Return Pixel Clock + 

34 

Return Pixel Clock 

17 


35 

Return Pixel Shield 

18 

Video Data + 

36 

Video Data - 

19 

Video Data Shield 

37 



^ Shield must be terminated to connector shell as well as to pin 1, and must not be connected to any other 
pin. 
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MECHANICAL CHARACTERISTICS OF INTERFACE 


b) Type-B cable assemblies shall use the following pin assignments for each 50-pin 
plug: 


Pin No. 

Signal 

Pin No. 

Signal 

Pin No. 

Signal 

1 

Overall shieldl 





2 

Power Control + 

18 

Power Control Shield 

34 

Spare + 

3 

Power Control — 

19 

Spare Shield 

35 

Spare — 

4 

Command + 

20 

Command Shield 

36 

Status + 

5 

Command — 

21 

Status Shield 

37 

Status — 

6 

Byte Clock + 

22 

Byte Clock Shield 

38 

Line Sync + 

7 

Byte Clock — 

23 

Line Sync Shield 

39 

Line Sync — 

8 

Page Sync -f- 

24 

Page Sync Shield 

40 

Return Byte Clock +• 

9 

Page Sync — 

25 

Return Byte Clock Shield 

41 Return Byte Clock ~ 

10 

Video Data 1 + 

26 

Video Data 0 Shield 

42 

Video Data 0 + 

11 

Video Data 1 “ 

27 

Video Data 1 Shield 

43 

Video Data 0 — 

12 

Video Data 3 + 

28 

Video Data 2 Shield 

44 

Video Data 2 + 

13 

Video Data 3 - 

29 

Video Data 3 Shield 

45 

Video Data 2 — 

14 

Video Data 5 + 

30 

Video Data 4 Shield 

46 

Video Data 4 + 

15 

Video Data 5 - 

31 

Video Data 5 Shield 

47 

Video Data 4 — 

16 

Video Data 7 + 

32 

Video Data 6 Shield 

48 

Video Data 6 + 

17 

Video Data 7 — 

33 

Video Data 7 Shield 

49 

Video Data 6 — 
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c) 

Type-C cable assemblies shall use the Type-A pin 

assignments given above for the 37 


pin plug^ and shall use the pin assignments given 

below for the 50-pin plug. 

Pin No. 

Signal 

Pin No. 

Signal 

Pin No. 

Signal 

1 

Overall shieldl 





2 

Power Control + 

18 

Power Control Shield 

34 

Spare + 

3 

Power Control — 

19 

Spare Shield 

35 

Spare — 

4 

Command + 

20 

Command Shield 

36 

Status + 

5 

Command — 

21 

Status Shield 

37 

Status — 

6 

Pixel Clock + 

22 

Pixel Clock Shield 

38 

Line Sync + 

7 

Pixel Clock — 

23 

Line Sync Shield 

39 

Line Sync — 

8 

Page Sync + 

24 

Page Sync Shield 

40 

Return Pixel Clock -1- 

9 

Page Sync — 

25 

Return Pixel Clock Shield 

41 Return Pixel Clock — 

10 


26 


42 


11 


27 


43 



'I Shield must be terminated to connector shell as well as to pin 1, and must not be connected to any other 
pin. 
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MECHANICAL CHARACTERISTICS OF INTERFACE 


Pin No. 

Signal 

Pin No. 

Signal 

Pin No. Signal 

12 


28 


44 

13 


29 


45 

14 


30 


46 

15 


31 


47 

16 

Video Data + 

32 


48 

17 

Video Data - 

33 

Video Data Shield 

49 


50 


9.3.3 Cable lengthy routing and handling 


Cable assemblies may be any length up to 50 feet maximum. 
The length of the cable is measured from the PSP interface to the 
lOT interface, as the interfaces are defined in section 9.1 above, 
i.e., the plugs on each end are included. 

Internal or external routing and securing must not subject either 
cable to a bend radius of less than five times its maximum 
diameter. 

The maximum diameter of the 9-pair cable is 0.595 inches, and 
the maximum diameter of the 16-pair cable is 0.650 inches. A 
bulkhead hole approximately 0.69 x 2.88 inches is required to 
pass through the 37-pin plug. A bulkhead hole approximately 
1.0 X 2.75 inches is required to pass through the 50-pin plug. 

The overall shield is covered by a protective insulated jacket, 
and must be grounded only through the shells and the assigned 
pins of the plugs and their mating receptacles. It must not be 
grounded at any other point in the cable run. 

The prescribed cables will have the UL2919 rating. They are not 
plenum rated. 
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MECHANICAL CHARACTERISTICS OF INTERFACE 


Figure 9-2. Physical location of generic interfaces 


lOT 3ACKPANEL 
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10. Standards agency compliance 


10.1 Safety 


The presecribed interface has been designed with the 
express intent that incorporation into a product will not 
jeopardize compliance of that product with the following 
safety reguirements: 

UL 478 

CSA C22.2 No. 154 

iEC 950 (This new standard supersedes lEC 380 and lEC 
435.) 

The cables prescribed herein will have UL2919 rating. They 
are not plenum rated. 

The interface prescribed herein will not provide power 
isolation per VDE 0804/572 and BPO Technical Guide No. 26, 
which is required by certain European PTTs. Such isolation 
must be provided in the PSP power supplies and in the lOT 
power supplies, or by means of special isolation 
arrangements at the telephone line interface in the PSP, or by 
a specially-designed PSP/IOT interface. 

Each product program remains responsible for compliance 
with the appropriate safety standards. 


10.2 Electro-magnetic emissions (EME) 


The prescribed interface has been designed with the express 
intent that incorporation into a product will not jeopardize 
compliance of that product with the following EME 
requirements; however, each product must individually 
demonstrate compliance: 

FCC Subpart J Part 15 Level A 
VDE 0871 Level A 
VDE 9875 
82/499/EEC1 

0 A new emission standard has been prepared by CISPR 
and published as CISPR 22. It is anticipated that within the 
next 18 months, it will replace 82/499/EEC and may also be 
adopted by the FCC. This new standard has two classes of 
limits, similar to current VDE and FCC specifications. 
5/13/86.) 

Each product program remains responsible for compliance 
with the appropriate emission standards. 
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B. Operating sequence examples^ 

scheduling offset of 3 


Following are seven of the eight operating sequence examples 
given in section 6.5, with scheduling offset equal to 3 instead of 
1 . 

Figure B6-7-a. Simplex cycle-up sequnce 
(scheduling offset = 3) 





- SCHEDU 

LING OFFSET « 3 - 

- 






1 

Cycl«dUp ^ 

1 


H 3 

R 

1 

1 

H. 

Rj He 


Y 

Y 

Y 

Y 


Y 

Y 


Y Y 


-. -A - 

t 


1 

.. 1 ...--. 

I 




imaga 1 

L 

1 A ^ 



k 

k 

k 



k 

N 

k 

1 CyeLUp 



Pi 

P 2 

P 3 



p Paga Sync 

Ps 

NBR 











R 3 He 

R 4 H, 

CO 

I 

a: 

Re H, 

R 

'7 

H 10 

Rs Hn 


T T 

Y 

Y 

Y Y 

Y Y 


Y 

Y 


Y Y 


lmag« 2 

imaga 3 

Imag. 4 


“U 

Imag* € 

Lj 

I Imaga 7 

[_ 


k 


k 

k 

k 



k 


k 


Pa 


P 7 

Ps 

P 9 



P 10 


P11 


Rq o - Request for a Dead Cycle (DC) 

R„ :: = n-th ’’Hint, Print, Request” triplet. (Only sheet nos. are shown.) 
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OPERATING SEQUENCE EXAMPLES, SCHEDULING OFFSET OF 3 


Figure B6-7-b. Simplex cycle-down sequnce 

(scheduling offset = 3) 



TT TT TT TT YY YY 



A A 

^ 0,0 ^ 0,0 


^ 0,0 * "Hint” Dead Cycle (DC) 

Pg g :: s Print Dead Cycle 

Rq g = Request for a Dead Cycle 

Pn R„ :: = n*th "Hint, Print, Request” triplet. (Only sheet nos. are shown.) 
NBR s NextBankRequest 
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OPERATING SEQUENCE EXAMPLES, SCHEDULING OFFSET OF 3 


Figure B6-8. Duplex cycle-up sequence 

(scheduling offset = 3) 

(Storing duplex paper path, minimum duplex offset 
= 9) 



■< — 

——- SCHEDULING 

i OFFSET » 3 -^-j 




1 

Cycl^dUp 1^1,1 

H2,1 

*^3,1 ^1,1^4,1 

P 

*2,1^5,1 


T 

Y 

Y 

Y T T 


Y Y 


.A - 

1 

1 

! 1 


Imagp 1,1 

“L 

1 


A 

A A 

A 

\ 

A 

1 Cycl«Up 


Pi,i 

P2,1 P3,1 

^ Pag« Sync 

P5,1 

NBR 



Minimum Ouplax Olfaat » 9 ►[ 



^3.1 ^6,1 

Ra.iHr,, 

^5,1^8,! 

^8,1*^9,1 ^7,1^1,2 

F 

U,1^ 10,1 


Y Y 

Y Y 

Y Y 

Y Y Y Y 


Y Y 


im«p« 2,1 

Imaga 3,1 

Imaga 4,1 

lmag« 5,1 Lj 

"TJ 

I Imag# 7,1 

L 


1 

A 

k k 

i 


A 


P«.1 

P7,1 

^8,1 ^9.1 

Pl,2 


^10,1 

^9.1 *^2,2 

Pl,2*^11,1 

PlO,1*^3,2 

^2,2*^12,1 ^11,1^4,2 

F 

*3,2^13,1 


Y Y 

Y Y 

Y Y 

Y T Y Y 


Y Y 


Imag* 8,1 

j^J Imapp 9,1 

Imaga 1,2 

Imaga 10,1 imaga 2,2 

“U 

1 tmaga 11,1 

“T_ 


1 

A 

A A 

A 


1 


^2,2 

Pii.i 

P3,2 Pl2,1 

P4,2 


^13,1 

*^12,1*^5,2 

^4,2*^14,1 

Pl3,1^8,2 

^5,2^15,1 Pl4,1^7,2 

^8,2*^16,1 


Y Y 

T T 

Y Y 

Y Y Y Y 


Y Y 


imaga 3,2 

Imaga 12,1 

Imaga 4.2 

Imaga 13,1 Imaga 5,2 

L 

1 Imaga 14,1 



A 

A 

A A 

A 


A 


P5,2 

Pl4,1 

Pe,2 Pi5,i 

P7,2 


Pl6,1 

*^^15,1*^ 8,2 

^7,2^17,1 

Pie,i^9,2 

P8.2*^18,1 Pl7,1^10,2 

^9.2^19,1 


Y Y 

Y Y 

Y Y 

Y Y Y Y 


Y Y 


lmag« 6,2 

Imaga 15,1 

Imaga 7.2 

Imaga 16,1 Imaga 8,2 

L 

J Imaga 17,1 

L 


A 

A 

A A 

A 


A 


Pa,2 

Pl7.1 

P9,2 Pl8,1 

Pl0,2 


Pl9,1 


^i.j P|,i Pt,i ” 

3 "Hint, Print, Request” triplet for sheet i, plate j. 




j 

3 PtateNumber 






PtateNumber : 

: 3 simplex side | duplex side 





simplex side :: 

3 1 






duplex side :: 

3 2 
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OPERATING SEQUENCE EXAMPLES, SCHEDULING OFFSET OF 3 


Figure B6-9. Duplex cycle-down sequence 

(scheduling offset = 3) 

(Storing duplex paper path, minimum duplex offset 
= 9) 





- SCHEDULlNt 

3 OFFSET = 3 -►-j 


^12,1*^ 5,2 

P4,2*^14,1 

*^13,1*^6,2 

P5,2*^15,1 

Pl4,1*^7,2 P6,2**16,1 


T T 

Y Y 

Y Y 

Y Y 

Y Y Y Y 


^jhiTiag* 3,2 | 

imag* 12,1 

Imag* 4.2 

Imag* 13,1 

Imag* 5,2 Imag* 14,1 

L 



A 

A 

A A 

A 

Pag* Syne ^ 

Pl4,1 

P6,2 

Pl5,1 P7,2 

Pi6.1 

^15,1*^8,2 

P7,2*^17,1 

^16,1^9.2 

^8.2*^ 18,1 

^17,1*^10,2 P9.2**19,1 


Y Y 

Y Y 

Y Y 

Y Y 

Y Y Y Y 


imag* 6,2 j 

Imag* 1S,1 

Imag* 7,2 

Imag* 16,1 

Imag* 8,2 imag* 17,1 

L 

i 


k 

A 

A A A 

A 

^8,2 

*^17,1 

P9,2 

Pl8,1 I Pl0,2 

NBR 

End'Of'job @ Sli**t 19 

Pl9,1 

^18,1^11,2 

^10,2*^12,2 

^19,1^13,2 

Pi 1,2*^ 14,2 

Pl2,2**15,2 ^13,2*^16,2 


Y Y 

Y Y 

T T 

Y Y 

Y Y Y Y 


imag* 9,2 

Imag* 18,1 

Imag* 10,2 

Imag* 19,1 

Imag* 11,2 Imag* 12,2 

L 

i 


A 

A 

A A 

A 

^11,2 

Pi 2.2 

Pi 3.2 

Pl4,2 Pl5,2 

Pl6,2 

^14,2*^17,2 

^15,2*^18,2 

*^16,2*^19,2 

Pl7,2*^0,0 

*^18,2*^0,0 P 19,2*^ 10,0 


Y Y 

Y Y 

Y Y 

Y Y 

Y Y Y Y 


imag* 13,2 

Imag* 14,2 

Imag* 15,2 

Imag* 16,2 

Imag* 17,2 Imag* 18,2 


A 


A 

A 

A A 

i. 

^17,2 

Pl8,2 

Pl9,2 

Po,o Pq.o 

Pq.o 

f^0,0 *^0.0 

*^0.0*^ 0,0 

Po,o 

Po.o 

Pq.o 


Y Y 

Y Y 

Y 

Y 

Y 


Imag* 19,2 

1 

DC 

1 . 

DC 

f 

DC DC 

1 -. i 


A 


A 




Po.o 

Po,o 





H, j Pj j R|j :: s ’’Hint, Print, Request” triplet for sheet i, plate j. 
j :: s PiateNumber 

PlateNumber :: s simplex side | duplex side 

simplex side :: s 1 
duplex side :: s 2 

NBR :: s NextBankRequest 
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OPERATING SEQUENCE EXAMPLES, SCHEDULING OFFSET OF 3 


Figure B6-10. Duplex-to-simplex transition 

(scheduling offset = 3) 

(Storing duplex paper path, minimum duplex offset 
= 9) 







r — 

SCHEDULING OF 

FSE1 

r s 3 - 



^4,2 ^14,1 

**13,1*^ 8,2 

fl 

’5,2**15,1 ** 

t4,ll^7.2 

P 

*6,2** 16,1 

**15,1** 8,2 


> 

f Y 

J 

f Y 

J 

Y Y 

Y Y 

J 

Y Y 

Y Y 


J 

ima 9 « 12.1 | 

Imaga 4,2 | 

Imaga 13,1 

Imaga 5,2 | 

Imaga 14,1 | 

Imaga 8,2 j 


\ A 


X 


X 

X 


X 

X 


P« 9 *Syne ^ 

**6,2 

**15,1 

**7,2 

*^16,1 **8,2 

F 

*7,2*^17,1 

^16,1^9,2 

fl 

*8,2** 18,1 ^ 

17,1** 10,2 

F 

*9,2** 19,1 

**18,1**11,2 


J 

T T 


Y Y 

J 

Y Y 

Y Y 

J 

Y Y 

Y Y 


Imaga 15, t j 

J 

Imaga 7,2 | 

Imaga 18,1 

Imaga 8,2 | 

Imaga 17,1 j 

Imaga 9,2 | 


X 


X 


X 

X 


X X 

X 



^17,1 

**9,2 

**18,1 

^10,2 

1 ^19,1 ^11,2 

NBR 

Simplax (§ Shaat #20 

F 

*10,2*^12,2 

**19,1**13,2 

F 

*11,2** 14,2 ** 

12,2**15,2 

**13,2** 16,2 

^14,2** 17,2 



T T 

u 

Y Y 

u 

Y Y 

Y Y 

u 

Y Y 

Y Y 

L 

J 

1 imaga 18,1 | 

imaga 10,2 | 

Imaga 19,1 

Imaga 11,2 j 

Imaga 12,2 | 

Imaga 13,2 j 


X 


X 


1 

X 


X 

X 



^12,2 

**13,2 

^14,2 

**15,2 

^16,2 ^17,2 









duplax papar path daplated —• 

I 

^15,2*^18,2 

**16,2*^19,2 

R 

17,2*^20,1 ^ 

18,2**21,1 

^19,2^22,1 

**20,1** 23,1 



Y Y 

L 

Y Y 

u 

Y Y 

Y Y 


Y Y 

Y Y 


1 Imag* 14,2 

1 Imaga 15,2 

1 Imaga 16,2 

1 Imaga 17,2 

L 

1 Imaga 18,2 

Imaga 19,2 

L 


X 


X 


X 

X 


X 

X 



^18,2 

**19,2 

**20,1 

**21,1 

**22,1 **23,1 

R 

21,1*^24,1 

R 

22,1 **25,1 

R 

23,1**26,1 ** 

24,1** 27,1 

R 

25,1 **28,1 

**26,1** 29,1 



Y Y 

L 

Y Y 

L 

Y Y 

Y Y 

L 

Y Y 

Y Y 

L 


J Imaga 20,1 

1 Imaga 2i,i 

j Imaga 22,1 

j Imaga 23,1 

1 Imaga 24,1 

Imaga 25,1 


X 


X 


X 

X 


X 

X 



**24,1 

**25,1 

**26,1 

**27,1 

^28,1 **29,1 


H, j P, j R| j :: s "Hint, Print, Request” triplet for sheet i, plate j. 
j :: s PlateNumber 

PlateNumber :: = simplex side | duplex side 

simplex side ::s 1 
duplex side :: s 2 

NBR ::s NextBankRequest 
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OPERATING SEQUENCE EXAMPLES, SCHEDULING OFFSET OF 3 


Figure B6-11. Simplex abort sequence 

(scheduling offset = 3) 


SCHEDULING OFFSET a 


T T 


R 5 Hg 

T T 


Rg Hg 

T T 


R7 

T Y 


Rs *^11 

T Y 


Rg H,2 

Y Y 



Hg o "Hint" Dead Cycle (DC) 

Pg Q s Print Dead Cycle 

Rq 0 :: - Request for a Dead Cycle 

H„ P„ Rp :: s n-th "Hint, Print, Request" triplet. (Only sheet nos. are shown.) 
SBA :: s SheetBankAbort 
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OPERATING SEQUENCE EXAMPLES, SCHEDULING OFFSET OF 3 


Figure B6-12, Duplex abort sequence, 

sheet abort during simplex side imaging 

(scheduling offset = 3) 

(Storing duplex paper path, minimum duplex offset 
= 9) 


^ - 

- SCHEOUUNC 

3 OFFSET 

* 3 - 

“1 


^12,1^5,2 ^4,2^14,1 ^13,1*^e,2 

^5.2*^15,1 

^14,1^7,2 

*^6,2 **18,1 


T Y T T T Y 

Y Y 

'I 

f Y 

Y Y 


3,2 Imag* 12,1 Imaga 4.2 j 

Imaga 13,1 

“U 

Imaga 5,2 | 

Imaga 14,1 

L. 

1 k k 


k 

k 


k 

Pag. sync ^ P, 4 ., P^.a 

**15,1 

^7,2 

*=*16,1 

^15,1^8,2 ^7,2^17,1 ^0.0 *^9,2 

*^8.2*^15,1 

^0,0 *^10,2 

^9.2**16,1 


Y Y Y Y Y Y 

Y Y 


Y Y 

Y Y 


|imag«6,2 I I I lmag« 7,2 I 

mmmJ L«J (dUcard) LmmmA I 

k k k k 

DC 

1.. L. . 


Imaga 8,2 

_ 



k 

k 


k 

^8,2 I ^10,0 ^9,2 

Pl5,1 

^10,2 

Pl6,1 

SBA 

Shaat « 1S 






^1S,1^11,2 ^10,2*^17,1 ^18,1*^12,2 

*^11,2*^18,1 

^17,1*^13,2 

**12,2**19,1 


Y Y Y Y Y Y 

Y Y 


Y Y 

Y Y 


imaga 9,2 ^JlmagalS,1 Imaga 10,2 

imaga 16 J 

”U 

imaga 11,2 

I [ Imaga 17,1 

“L 

k k k 



k 


k 

*^11,2 ^17,1 ^12,2 

^18,1 

^13,2 

^19,1 

^18,1*^14,2 *^13,2*^20,1 *^19,1*^15,2 

*^14,2*^21,1 

^20,1^16,2 

**15,2** 22,1 


Y Y Y Y Y Y 

Y Y 


Y Y 

Y Y 


itnaga 12,2 Imaga 18,1 imaga 13,2 

Imaga 19,1 

L 

1 Imaga 14,2 

Imaga 20,1 


k k k 


k 

k 


i. 

^14,2 ^20,1 ^15,2 

^21,1 

^16,2 

*^22,1 


:: s "Hint, Print, Request” triplet for sheet i, plate j. 
j :: s PlateNumber 

PlateNumber :: s simplex side | duplex side 

simplex side ::s 1 
duplex side = 2 

SBA ::3 SheetBankAbort 
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OPERATING SEQUENCE EXAMPLES, SCHEDULING OFFSET OF 3 


Figure B6-13. Duplex abort sequence, 

sheet abort during duplex side imaging 

(scheduling offset = 3) 

(Storing duplex paper path, mininaum duplex offset 
= 9) 
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SCHEDULINC 

5 OFFSET » 3 - 

- >■ 
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"1 
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OC 

t (discard Sh. 5 ) 
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X 

Paga Sync 
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i (diacard Sh. 
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OC 

9 ) 1 (discard Sh. 10 ) 


OC 

1 (discard Sh. 11 ) 

DC 

1 (discard 
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X 


X 

X 
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X 
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X 
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Y Y 

Y Y 
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X 

X 
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P4,2 
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imaga 13,1 

Imaga 5,2 

L 

A 

X 

X 

^ 8,2 

P 15.1 
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H| j P, j R, j :: s "Hint, Print, Request" tripiet for sheet i, plate j. 
j :: s PlateNumber 

PlateNumber :: s simplex side | duplex side 

simplex side :: s 1 
duplex side :: s 2 

SBA = SheetBankAbort 


I afA XEROX 
Private 
▼Av Data 
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C. Operating sequence examples^ 

bindexer destination 


Following are three operating sequence examples which 
supplement those shown in section 6.5 and appendix B. The 
assumptions are: 

a) Two collated copies to a bindexer, 

b) Scheduling Offset = 1, 

c) Racetrack duplex paper path, DuplexOffset = 8. 


Figure C6-7-a. Simplex cycle-up sequence 

(2 copies/bindexer destination) 


t 


NBR 


SCHEDULING OFFSET : 1 


Cycl#dUp 


R1.1H1.2 F 

*1,2*^ 2,1 

^2,1^2,2 P2,2*^3,1 

Y 

T 

T T 

r Y 

Y Y Y Y 



1 

lm«9« 1,1 

Image 1,2 Image 2,1 


1 

1 

\ 

Ilk 

CycitUp 

Pi.i 

P, 2 Pag# Syne 

^2,1 ^2,2 ^3,1 


Rq 0 :: - Request for a Dead Cycle (DC) 

Hn c Ri,e Rn.c ”= n-th "Hint, Print, Request" triplet, (c s CopyNumber) 
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OPERATING SEQUENCE EXAMPLES, BINDEXER DESTINATION 


Figure C6-7-b. Simplex cycle-down sequence 
(2 copies/bindexer destination) 

SCHEDULING OFFSET « 1 
^ rt 2^00 ^ 00^00 ^ 00^00 ^00 


T T T Y T T T T T T T 



NBR 

End'Of-Job ® ShMt n 



Hq 0 :: a "Hint" Dead Cycle (DC) 

Pq g a Print Dead Cycle 

Rg g :: a Request for a Dead Cycle 

Hn e f?,,e Rn,e •• = n>th "Hint, Print, Request" triplet, (c a CopyNumber) 
NBR :: a NextBankRequest 
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OPERATING SEQUENCE EXAMPLES, BINDEXER DESTINATION 


Figure C6-8. Duplex cycle-up sequence (2 copies/bindexer 
destination) 

(scheduling offset =1) 

(Race Track duplex paper path, duplex offset = 8) 
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Imaga 5,1,1 


Imaga 5,1,2 
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imaga 7,1,1 
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^ 5 , 1,2 
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H, j g P, j g R, j g :: = "Hint, Print, Request” triplet for sheet i, plate j, copy c. 

Is SheetNumber 
j :: s PlateNumber 
c :: s CopyNumber 

PlateNumber :: s simplex side | duplex side 

simplex side :: s 1 
duplex side :: s 2 
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OPERATING SEQUENCE EXAMPLES, BINDEXER DESTINATION 


Figure C6-9. Duplex cycle-down sequence 
(2 copies/bindexer destination) 

(scheduling offset =1) 

(Race Track duplex paper path, duplex offset = 8) 






”•* "Hint, Print, Request” triplet for sheet i, plate j, copy c. 

i:: s SheetNumber 
j :: s PlateNumber 
c:: s CopyNumber 

PlateNumber ::s simplex side {duplex side 

simplex side :: s 1 
duplex side :: s 2 
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D 


Recommended circuitry for 
power control interface 


PSP control of lOT AC power Is specified in section 8.4. The 
circuit shown In figure D-1 is recommended to implement this 
function. 

The control actuator in the lOT may be a solid state or 
conventional relay of not less than 120 ohms. R4 must limit the 
short circuit current, power control + to ground, but allow 
nominal 50 ma load current. The worst case conditions for the 
latter are: power supply at lower limit of 11.4V, voltage drop 
across sinking transistor Q1 maximum of 0.4V, and R4 at its high 
tolerance end-of-life value, designated R4'. Under these 
conditions, R4' = 100 ohms, and R4 = 100/1.09 =91.7 ohms. 
For power dissipation reasons. It is recommended that R4 be 
composed of six 560 ohm 0.5 watt resistors in parallel, which 
provide an effective resistance of 93.33 ohms and effective 
power rating of 3 watts. With this value, the lowest current in a 
120 ohm load is 11V/(120 + 1.09(93.33)) = 49.6 ma, the worst 
case short circuit current with R4 at low-tolerance, end-of-life 
value is 12.6V/(.91(93.33)) = 148.4 ma, and the corresponding 
worst-case power dissipation in R4 is 1.87 watts. Note that the 
effective power rating of R4 represents a derating of 
approximately 62 percent. This is less conservative than the usual 
50 percent derating for continuous operation, but is sufficient to 
prevent damage to the resistors or to a printed wire board (max. 
allowable surface temperature = 122 degrees C) during this 
abnormal condition. A more conservative derating can be 
obtained by using eight 750 ohm 0.5 watt resistors, if desired. 
The highest current which the power source must supply to a 
120 ohm load occurs with the power supply at its high limit of 
12.6V, the voltage drop across Q1 at its minimum of 0.2V, and 
R4 at its minimum of .91(93.33) ohms. Under these conditions, 
the current is 60.5 ma. Under the same conditions, the highest 
voltage across a 50 ma load will be 8.15V. 

R5 is to be selected so as to meet the operating requirements of 
the chosen control actuator, and is to be considered part of the 
load. For example, consider a nominal 6V relay with a 180 ohm 
±10% coil, and a pull-in requirement of 4.8V. With a voltage 
pull-in requirement, the worst case which must be considered is 
minimum supply voltage (11.4V), maximum voltage drop across 
Q1 (0.4V), maximum end-of-life resistance of R4 (101.7 ohms), 
minimum coil resistance (162 ohms), and maximum end-of-life 
resistance of R5 = R5*. The current required in the 162 ohm coil 
to produce 4.8V is 29.6 ma. Under these conditions, R5 = 
R5V1.09 = 98.7 ohms. To guarantee 4.8V across the coil, the 
next lower standard value is chosen, 91 ohms. With this value at 
high end of life, 99.2 ohms, the guaranteed minimum coil 
voltage is 4.91V. The worst-case power dissipation in R5 occurs 
with maximum supply voltage of 12.6V, minimum drop across Q1 
of 0.2V, minimum value for R4 of 84.9 ohms, minimum coil 
resistance of 162 ohms, and maximum value for R5 of 99.2 ohms. 
It is 0.127 watts. 

Consideration must also be given to the maximum power rating 
of the relay. The maximum operating current for this example is 
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RECOMMENDED CIRCUITRY FOR POWER CONTROL INTERFACE 


with maximum supply voltage of 12.6V, minimum drop across Q1 
of 0.2V, minimum values for R4 and R5 of 84.9 and 82.8 ohms, 
respectively, and minimum coil resistance of 162 ohms. Under 
these conditions, the operating current is 37.6 ma, and the 
power dissipation in the coil is 0.229 watts. The maximum 
operating voltage across the coil occurs with all conditions the 
same, except coil resistance = 198 ohms. Under these 

conditions, the coil voltage is 6.7V and the power dissipation in 
the coil is 0.228 watts. These results would have to be checked 
against the power rating of the relay. 

The active control circuitry has been designed with the following 
strategy. The -fS.IV power for parallel gates B and C, which 
drive the output transistor Q1, is derived from the +12V source 
and will, thus, be into stable regulation following main power 
turn-on in the PSP, prior to both the +12V supply and to the 
+ 5V Vcc supply. The Power Normal signal is designed to remain 
low until the Vcc supply is into stable regulation. Thus, power 
control + is guaranteed to remain firmly in the off state during 
main power turn-on, and all elements of the control circuitry are 
guaranteed to be stable before the Power On signal can be 
effective at the interface. Chattering of the power actuator in the 
lOT, due to transient power supply anomalies in the PSP, is 
thereby avoided. The sequence is reversed during main power 
turn-off. That is, Power Normal goes low prior to Vcc leaving 
stable regulation, and thus also prior to T-12V and +5.1V leaving 
stable regulation. Thus, power control + is guaranteed to be 
firmly in the off state during main power turn-off. 

Diodes D1 and D2 prevent transient noise as great as 20 volts on 
the interface leads from changing either normal logic state of 
parallel driving gates B and C. Zener diode D3 and associated 
components assure that Q1 is controlled by gates B and C, and 
that the control is glitch free. These gates operate on supply 
voltage as low as 2V, and thus maintain control longer than any 
other circuits during the main power on and off transition 

RC filters at the inputs to NAND gate A remove noise on the 
Power On and Power Normal signal lines. However, once the 
Power Normal signal goes high, any glitch or noise greater than 
the logic threshold and longer than 10 microseconds on the 
Power On line can change the output state. 
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RECOMMENDED CIRCUITRY FOR POWER CONTROL INTERFACE 


Figure D-1. Recommended circuitry for power control 
interface 


♦ 12Y ♦/.$% 



Part Numbara: 


D1 7O7WO1907 
02 707W01987 
03 707W00160 
Q1 707W00081 
Qataa 733W03033 
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Alternate imaging modes 


The primary imaging mode addressed by this specification is 
single color, 1 bit per pixel. (This includes full color when the 
individual color plates are transferred sequentially.) Alternate 
imaging modes such as trilevel higlilight color (2 bits per pixel) 
and 2'^ level grey scale, where n is integer 2 to 8, can also be 
accommodated. It is only necessary to follow prescribed signal 
formats at the interface. 

Single-color (or full-color, sequential plate) is multiplexed onto 
the eight data paths of the parallel video data interface as 
specified in § 3.1.3.1, i.e., earliest bit of a scan line octet on 
Video Data 7, latest bit of an octet on Video Data 0. The 
alternate imaging modes are to be handled as follows and are 
summarized in figure E-1. 

Trilevel Highlight Color (2 bits per pixel) shall be transferred 
four pixels at a time via the eight data paths of the parallel video 
data interface. The LSBs (least significant bits) of the latest 
through earliest pixels shall be transmitted on Video Data 0, 2, 
4, and 6, respectively, and the MSBs (most significant bits) of the 
latest through earliest pixels shall be transmitted on Video Data 
1, 3, 5, and 7, respectively. This provides up to 100 Megapixels 
per second. This recommendation applies to all speeds, even 
though lower pixel rates could be accommodated with fewer 
signal paths. The objective here is to minimize the number of 
product configurations. 

For grey scale, signals with 8, 4, and 2 bits per pixel will utilize 
the full video bandwidth when multiplexed onto the 8 video data 
lines of the interface. Signals with 3, 5, 6, and 7 bits per pixel 
will utilize less than the full video bandwidth. 

256-level grey scale (8 bits per pixel) shall be transferred one 
pixel at a time via the eight data paths of the parallel video data 
interface. The least significant bit shall be transmitted on Video 
Data 0 and the most significant bit shall be transmitted on Video 
Data 7. This provides up to 25 Megapixels per second. 

16-level grey scale (4 bits per pixel) shall be transferred two 
pixels at a time via the eight data paths of the parallel video data 
interface. The LSB of the later pixel of a pixel pair (dipixel) shall 
be transmitted on Video Data 0, the MSB of the later pixel on 
Video Data 3, the LSB of the earlier pixel of a dipixel on Video 
Data 4, and the MSB of the earlier pixel on Video Data 7. This 
provides up to 50 Megapixels per second. 

4-level grey scale (2 bits per pixel) shall be transferred four 
pixels at a time via the eight data paths of the parallel video data 
interface. The LSB of the latest pixel of a 4-pixel nibble shall be 
transmitted on Video Data 0, the MSB of the latest pixel on 
Video Data 1, the LSB of the later pixel on Video Data 2, the 
MSB of the later pixel on Video Data 3, and so on, as shown in 
figure E-1-A. This provides up to 100 Megapixels per second. 

8-level grey scale (3 bits per pixel) shall be transferred two 
pixels at a time via six of the eight data paths of the parallel 
video data interface. The LSB of the later pixel of a pixel pair 
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(dipixel) shall be transmitted on Video Data 0, the MSB of the 
later pixel on Video Data 2, the LSB of the earlier pixel of a 
dipixel on Video Data 4, and the MSB of the earlier pixel on 
Video Data 6. Less than the full bandwidth of the interface is 
utilized, as shown in figure E-1-B. This provides up to 50 
Megapixels per second. 

2n-level grey scale, where n is 5, 6, or 7, shall be transmitted 
one pixel at a time. In each case, the least significant bit of each 
pixel shall be transmitted on Video Data 0 and the most 
significant bit shall be transmitted on Video Data n-1. Thus, less 
than the full bandwidth of the interface is utilized for up to 25 
Megapixels per second in each case. 




XEROX 

Private 

Data 
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ALTERNATE IMAGING MODES 


Table E-1. Signal assignments for alternate imaging modes 


Generic 
path name 

Video signal assignments & clock definition 

Trilevel HLC 

Grey scale 
8-bit, 256-level 

Grey scale 

4-bit, 16-level 

Grey scale 

2-bit, 4-level 

video Data 0 

BA/V bit of latest pixel 

LSBit of pixel 

LSB of later pixel 

LSB of latest pixel 

Video Data 1 

RAA/ bit of latest pixel 

• 

• 

MSB of latest pixel 

Video Data 2 

BAA/ bit of later pixel 

• 

• 

LSB of later pixel 

Video Data 3 

R/W bit of later pixel 

• 

MSB of later pixel 

MSB of later pixel 

Video Data 4 

B/W bit of earlier pixel 

• 

LSB of earlier pixel 

LSB of earlier pixel 

video Data 5 

R/W bit of earlier pixel 

• 

• 

MSB of earlier pixel 

Video Data 6 

B/W bit of earliest pixel 

• 

• 

LSB of earliest pixel 

Video Data 7 

R/W bit of earliest pixel 

MSBit of pixel 

MSB of earlier pixel 

MSB of earliest pixel 

Video Clock 

Nibble Clock 

Pixel Clock 

DiPixel Clock 

Nibble Clock 


A. Highlight color and binary grey scale 



Video signal assignments & clock definition 

Generic 
path name 

Grey scale 

Grey scale 

Grey scale 

Grey scale 


7-biC 128-level 

6-bit, 64-level 

5-bit, 32-level 

3-bit, 8-level 

Video Data 0 

LSBit of pixel 



LSB of later pixel 

Video Data 1 

• 

• 

• 

• 

Video Data 2 

• 

• 

• 

MSB of later pixel 

Video Data 3 

• 

• 

• 

(not used) 

Video Data 4 

• 

• 

MSBit of pixel 

LSB of earlier pixel 

Video Data 5 

• 

MSBit of pixel 

(not used) 

• 

Video Data 6 

MSBit of pixel 

(not used) 

(not used) 

MSB of earlier pixel 

Video Data 7 

(not used) 

(not used) 

(not used) 

(not used) 

Video Clock 

Pixel Clock 

Pixel Clock 

Pixel Clock 

Dipixel Clock 


B. Non-binary grey scale 
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Change history 



The following is a brief description of the principal changes that 
have been made to the various sections of this document, 
subsequent to their initial piecemeal approval, and embodied in 
Version 2.0. Chapters 1, 2, 3, 4, 7, 8, 9, 10, and 11 were 
originally approved by the Print Standards Committee in 
December, 1984, and published as XSIS document number 
218412. Chapter 5, Command/Status Communications was 
approved in May, 1985, and chapter 6 Client Layer Protocol and 
related appendices A and B (now B and C) were approved in 
November 1985. 

General Reference to the Distributed Printing and Reprographic Systems 
(DPRS) architecture as the exclusive domain of this generic 
specification has been removed throughout the document. 

Chapter 1 The single criterion for designating high-end printers, i.e., video 
data rate 10 Megabits per second or greater, has been qualified 
by also including the type of data link required to support the 
speed and functionality of the printer. 

Chapter 2 Discussion of complex printing arrangements has been removed 
to new appendix E, and replaced by a reference to appendix E. 

Chapters Section 3.1.1. Added note to the effect that an lOT may 
implement more than one Standard Image Frame. 

Section 3.1.2. Added references to related information on page 
sync in sections 6.4.2 and 6.4.4. 

Section 3.2. The optional interface signals lOT Reset (formerly 
section 3.2.3) and Power Monitor (formerly section 3.2.5) have 
been deleted. To effect this change, the text and figures have 
been modified as follows: 

Section 3.2.3. This paragraph now contains an updated 
description of the Power Control interface signal and its 
function, plus references to related information in chapters 6 
and 8. 

Section 3.2.4. Deleted, subject moved to section 3.2.3. 
Section 3.2.5. Deleted. 

Figures 3.2 and 3.3. Power Monitor/IOT Reset signal 
removed. 

Section 3.3. Text has been rewritten and removed to new 
appendix E, and replaced by a reference to appendix E. 

Chapter 4 Section 4.1. Added reference to Page Sync regimen and 
operating sequences in chapter 6. 

Chapter 5 Section 5.2.1. Redirected reference to new appendix E. 

Section 5.3.9.e. Added reference to related information in 
chapter 6. Note on possible Ack time incompatibility upgraded 
from temporary to permanent note. 






CHANGE HISTORY 


Section 5.4.3. Added reference to related information in chapter 

6. 

Figure 5.7. Data Link Communication Sequence, updated for 
compatibility with chapter 6. 

Chapter 6 Section 6.2, 6.3. All paper width and paper length parameters 
have been changed from one byte to two bytes. To effect this 
change, the text and format sketches listed below have been 
modified accordingly: 


Section 6.2.1. Command 

PspNextBankRequest. 

parameter 

summary 

for 

Section 6.2.2. Status 

parameter 

summary 

for 


lotConfiguration and lotOperationalInfo. 

Section 6.3.2. Under PspNextBankRequest: 

parameter summary and transmission order sketch; 

formatted definition of Destination paper dimensions; 

application note explaining previous method of 
designating paper size. 

Section 6.3.3. Under lotConfiguration: 

parameter summary and transmission order sketch; 

formatted definition of TopTray, Stacker, MultibinSorter, 
Bindexer, and Feeder paper dimensions; 

application notes for information types, '"Destination" and 
"Feeder", and Feeder format sketch. 

Section 6.3.3. Under lotOperationalInfo: 

parameter summary and transmission order sketch; 

formatted definition of Feeder paper dimensions; 

application note for information type, "Feeder", and 
Feeder format sketch. 

Section 6.3.3. The 1-bit parameters in status message 
lotConfiguration indicating implementation or non¬ 
implementation of optional lOT Reset and Power Monitor 
interface signals have been deleted. (Refer to chapter 3 changes, 
above.) 

Section 6.4, 6.5, Appendices A and B. The timing of client layer 
command PspNextBankRequest has been moved one page-time 
earlier than previously prescribed. To effect this change, the text 
and figures have been modified as follows: 

Section 6.4.2. The last two sentences of this paragraph have 
been changed to describe the new timing relationship. 

Figure 6.4. The index of NBR has been changed from (n + x) to 
(n + 1+x). 

Figure 6.7-b. NBR(end-of-job @ sheet n) has been moved two 
page-times to the left (this was previously in error by one page¬ 
time too far to the right). 

Section 6.5.2. The sixth sentence has been changed to reflect 
the change in Figure 6.7-b. 

Figure 6.9. NBR(end-of-job @ sheet 19) has been moved one 
page-time earlier. 
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CHANGE HISTORY 


Chapter 7 


Chapter 8 


Chapter 9 


Section 6.5.4, Second sentence has been changed to reflect the 
changes in Figure 6.9. 

Figure B6.7-b (formerly A6.7-b). NBR(end-of-job @ sheet n) has 
been moved one page-time to the left. 

Figure B6.9 (formerly A6.9). NBR(end-of-job @ sheet 19) has 
been moved one page-time to the left. 

Figure C6.7-b (formerly B6.7-b). NBR(end-of-job @ sheet n) has 
been moved two page-times to the left, i.e., just preceding 
P(n,1) (this was previously in error, one page-time too far to the 
right). 

Section 7,2. The timing analysis has been redone using cable 
specifications from the actual issued drawings (results are slightly 
more favorable). 

Figure 7.3. Redrawn to agree with new timing analysis (see 
section 7 . 2 , above.) 

Section 8.1. Extent of the timing re-analysis recommendation has 
been limited to changes in video or return clock circuits. 

Section 8.2. Extent of the timing re-analysis recommendation has 
been limited to changes in video or return clock circuits. 

Section 8.3. Note about exception conditions added at end of 
paragraph. 

Section 8.4. Rewritten to reflect detailed circuit design for the 
Power control function now given in new appendix C. 
References to related information in chapter 6 added. 

Section 8.5. Text on Power Monitor/IOT Reset function deleted 
(see section 3.2 changes, above) and replaced with text on 
Detection of Cable and Power Status at the interface. 

Section 8,7. Added note that each cable now has a spare pair 
(result of dropping Power Monitor/IOT Reset function). 

Figure 8.5. Redrawn to reflect new Power Control circuit and 
deletion of Power Monitor/IOT Reset function. 

Figure 8.6. New figure showing Circuits for Detection of Cable 
and Power Status at Interface. Old Figure 8.6 relabled Figure 8.7. 

Figure 8.7. Connector symbols turned around to reflect actual 
construction. Interface demarcation lines identified. Old Figure 
8 . 6 . 

Section 9.1. Cender of PWB-mounted and cable-mounted 
connectors interchanged to reflect final design. 

Section 9.2.1. All Xerox part numbers are now included 

(vendor's part numbers deleted). 

Section 9.2.2. All Xerox part numbers are now included 

(vendor's part numbers deleted). 

Section 9.3. Power Monitor pin assignments changed to "spare" 
(see section 3.2 changes, above). Reference to complex printing 
arrangements deleted. 

Section 9.4.1. Reference to complex printing arrangements 

deleted. 

Section 9.4.2. Power Monitor pin assignments changed to 

"spare" (see section 3.2 changes, above). 
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Chapter 10 


Appendix A 

(formerly chapter 11) 

Appendix B 

(formerly appendix A) 

Appendix C 

(formerly appendix B) 

Appendix D 

(formerly appendix C 
in January 20, 1986 revision) 

Appendix E 


Appendix F 
Glossary 


Section 9.4.3. Gender of PWB-mounted and cable-mounted 
connectors interchanged to reflect final design. Dimensions of 
bulkhead holes added. 

Section 10.1. The I EC Standard citation has been changed from 
lEC 435 to lEC 950. This standard has recently replaced both lEC 
435 and lEC 380. Note that this paragraph is only advisory and, 
as such, does not state a requirement. 

Section 10.2 Corrected Agency designation in last standard 
reference to ''EEC." A note has been added concerning new 
emission standard, CISPR 22. Note that this paragraph is only 
advisory and, as such, does not state a requirement. 

All SDLC references replaced with HDLC references. Character 
code reference added. 

Refer to figures B6.7-b and B6.9 (formerly figures A6-b and 
A6.9) under chapter 6 changes, above. 

Refer to figure C6.7-b (formerly figure B6-7-b) under chapter 
6 changes, above. 

New text and new Figure D.1 on Recommended Circuitry 
for Power Control Function. Corrected value of resistor in 
base of Q1 from IK ohms (in January 20, 1986 revision) to 1.5K 
ohms. 

Text and figures on Complex Printing Arrangements (from old 
section 3.3) rewritten with newer information. This appendix 
now contains all discussion of this subject in this document. 
(The contents of this appendix are deleted in the OEM version of 
this document.) 

(Added.) 

(Added, formerly appendix D in January 20, 1986 revision.) 


V2.1 


The following is a brief description of the principal changes that 
have been made to Version 2.0 of this document, and embodied 
in Version 2.1. 

Chapter 6 Section 6.3.2. Under PspNextBankRequest, bits dO and d1 of the 
FutureFinishingOptions field have been assigned. 
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V2.2 


A number of changes to Version 2.1 were published on an 
interim basis as Addendum 1 (XNSCS 108810a, November 1988). 
All of these changes are now included in Version 2.2. 
Addendum 1 is therefore rendered obsolete by Version 2.2. A 
number of additional changes have also been included in Version 
2.2. All of the changes were requested by implementors. The 
following is a brief description of all the changes to Version 2.1 
which are embodied in Version 2.2. 

Chapter 6 New resolution parameter: 

Provision has been made in the command/status message 
structure to specify resolution from sheet to sheet and from front 
to back of the same sheet. Two lOT specific resolutions are 
available for each side. The commands affected are 
PspNextBankRequest and PspPrint. The status messages affected 
are lotVideoHint and lotVideoRequest. This change supercedes 
the change published in Addendum 1 which provided four lOT 
specific resolutions without simplex/duplex designations. 

BinFillLimit: 

This parameter of the PspNextBankRequest command and its 
associated application note have been modified to extend its 
applicability to different output devices and the units of 
measurement have been made lOT specific. 

InterruptJobASAP: 

The application note for this command function of 
PspNextBankRequest has been modified to allow alternatives to 
the preferred action of delivering an interrupting job to a 
different destination than the interrupted job. Section 6.4.4, "Job 
interrupt protocol/' has also been rewritten to be consistent with 
these changes. 

Diagnostic utility numbering: 

The PspRequestlotDiagnositc command and 

lotDiagnosticResponse status message have been restructed to 
expand the utility field from one byte to two byes, In accordance 
with the new Multi-National Standard for Diagnostic Program 
Numbers and Status Codes. 

Finisher action: 

Under the PspRequestlotAction command, definition of the 
Action field when device is Finisher has been expanded to 
provide the capability to turn the finisher off by command, to set 
a time-out interval to be used by the finisher to remove power 
from the finisher binder, and to set binder tape length to 
accommodate both U.S. and non-U.S. paper length with fine 
adjustments for variances in paper length. 

Numbering and sequencing conventions: 

Section 6.4.3 has been rewritten to allow that an lOT may 
concurrently manage multiple jobs in every job category, 
previous, current, next, and interrupted. The lotConfiguration 
status message has been modified to report the maximum 
capability in only the two essential categories, interrupted jobs 
and the total of all jobs. The associated application note is 


F-5 


HIGH-END lOT INTERFACE 2.2 



CHANGE HISTORY 


modified accordingly. Section 6.4.4, '"Job interrupt protocol/' 
has also been rewritten to be consistent with these changes. 

Machine Status and Substates: 

Under the lotStateInfo status message, the application notes for 
machine state CycledDownNotReady and machine substates 
FaultDetected and Nonproductive have been rewritten to 
eliminate an ambiguity which seemed to allow the Productive 
substate while in the CycledDownNotReady state. 

Feeder and Destination parameters: 

Under the lotOperationalInfo status message, the data fields for 
InformationTypes FeederN and InformationTypes DestinationN 
have been modified so that all the same attributes are reported 
for destinations as for feeders, and the feeder paper gauges and 
destination paper gauges have been made lOT specific. 

Page Sync regimen: 

Section 6.4.4 has been rewritten to require all lOTs to implement 
page sync so as to enable either a continuous page sync regimen 
or the previously defined regimen now referred to as the discrete 
regimen. This is to accommodate PSPs which accept only the 
continuous regimen or only the discrete regimen. Also, section 
6.4.4 now allows page sync to appear at the interface under the 
discrete regimen when dead cycles that occur during job 
processing are used for sending test images to the lOT. 

Stitch position: 

The stitch position parameters in the NlextBankTasklnfoC byte of 
the PspNextBankRequest command have been changed from an 
offset dimension to a position dimension and the measure has 
been made lOT specific. 

Message reject: 

The PspRejectlotMessage command and the 
lotRejectPspCommand status message have been restructured to 
include SheetNumber, CopyNumber, and JobNumber so as to 
uniquely identify which message is being rejected when these 
parameters are involved. 

Contrast control: 

Two new parameters, ContrastAction and ContrastData, have 
been added to the PspNextBankRequest command to give the 
PSP contract control capability. 

Belt speed: 

InformationType BeltSpeed and DataVVord Speedinfo have been 
added to the lotConfiguration status message to facilitate 
reporting belt speed. 

Crash recovery protocol: 

Section 6.4.7 on this subject has been rewritten to clarify which 
actions are performed by the data link layer and which are 
performed by the client layer. 

Appendix E The discussion of complex printing arrangements in Version 2.1 
has been replaced by specifications for handling alternate 
imaging modes, namely trilevel highlight color and grey scale. 
The OEM edition of Version 2.1, which was created by deleting 
the contents of appendix E, is now obsolete. There is no need 
for an OEM edition of Version 2.2. 
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background 
bank (parameter bank) 

bindexer 

bit-map 

Change Modification Entry (CME) 

Control Interface 

copy-set (copy) 


dead cycle 

duplex (printing) 


duplex (transmission) 


edge marking 


Following are the meanings of terms as used in this generic 
specification. They are not necessarily universal definitions. 

See Image background level. 

A set of parameters sent from the PSP to the lOT which 
describes how a series of images is to be processed with respect 
to paper source, output destination, finishing, color, simplex or 
duplex printing, etc. 

An lOT output device which accepts interleaved sheets of 
multiple copy-sets, collates the copy-sets simultaneously, and 
automatically ejects finished copy-sets to a stacker. 

The array of binary pixels which constitute an image, or one plate 
of a multiplate image. The array is in the form of a raster of 
sequential lines, each composed of a linear sequence of pixels. 

Changes to a plate or image which can be programmed to cause 
the otherwise identical plate or image to vary from copy to copy. 
Used, for example, to vary the Information added to the several 
copies of a form to produce subsets of the master copy. 

That part of the generic interface hardware and software which 
comprises the signalling channels for the Command, Status, and 
Power Control functions. 

The aggregate of sheets representing the complete set of 
sequential pages of a multi-page document as they appear at the 
output of the lOT. Copy-sets result at the output from collated 
delivery of single or multiple replications of multi-page 
documents. The abbreviated forms, copy or set may be used 
where there is no danger of ambiguity. 

A cycle or pitch of the marking engine during which page sync is 
suppressed at the interface by the lOT and the PSP's Imaging 
subsystem delivers no video data to the interface. If paper is 
already commited to this cycle, it is discarded at the output. 

Pertaining to a printing operation in which both sides of the 
paper are (or can be) imaged. Duplex printing is typically 
accomplished with two passes of a given sheet past a single 
imaging station, reversing sides between passes. (But see also 
Immediate Duplex and Simultaneous Duplex.) In a duplex 
printing operation, the duplex side of the paper is the back or 
reverse of the simplex side. See simplex printing. 

Pertaining to a point-to-point transmission system or facility in 
which information is sent in both directions simultaneously. 
Two-way simultaneous transnriission. 

Placement of non-background portions of an image at the 
extreme edge(s) of the paper. Such marking is intended to be 
visible when the paper is stacked with other sheets. Because of 
the necessity to allow for paper registration error, edge marking 
typically results in imaging non-background information beyond 
the edge(s) of the paper. 
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end of scan edge 


fast-scan 


gapless printer 


ground mecca 


high-end 


high-light color (also hi-!ite color) 


image (n*) 


image (v.) 


image background level 


Imaging Interface 


With respect to the Standard Image Frame or to the paper, the 
edge which is perpendicular to the fast scan direction, and which 
is imaged last in those imaging systems which sequentially deliver 
pixels of image raster lines. In those imaging systems which 
employ line arrays which may image the complete line, or 
segments of the line, simultaneously, it is the edge 
corresponding to the end of the array which is typically loaded 
last with the video data. 

Applied to the direction or dimension which is parallel to the 
lines of the image raster, i.e. perpendicular to the direction of 
motion of the output medium (paper) during imaging. 

A printer whose lOT images continuously from one page sync 
true transition to the next, i.e. there is no time gap nor spatial 
gap between the trailing edge of one Standard Image Frame and 
the leading edge of the next Standard Image Frame. This is 
characteristic of web feed lOPs. 

Common point within an lOT, or within a PSP, where frame 
ground and green wire ground of the AC power source are 
connected together. 

Applied to a printer, an lOT, or a PSP which has a total video 
data rate greater than 10 Megabits per second at the PSP/IOT 
interface and whose speed or functionality requires the 
synchronous data link described in chapter 5. 

A printer capability providing one (or more) image color(s) in 
addition to the principal image color provided by the printer, for 
example, red in addition to black. The additional color(s) is 
intended for relatively sparse usage on a page i.e. for highlighting 
a limited number of characters, words, or other elements of the 
image. Highlighting may be invokable at the pixel, character, or 
word level, depending on the design of the machine. The high¬ 
light color is not necessarily applied with the same marking 
means nor the same marking method as used for the principal 
color. See also trilevel hi-lite color. 

The totality of information which is applied to one surface of an 
10T*s output medium. Note that an image may comprise more 
than one plate, and that the same image may be applied to the 
corresponding surfaces of more than one sheet in a multicopy 
job. 

To cause image information, e.g. a plate, to be applied to the 
intermediate transfer medium, or directly to the output medium, 
of an lOT. 

The video data signal level corresponding to the background 
level of a positive image, i.e. an image in which the variable data 
is rendered optically more dense than non-variable data on the 
output medium. 

That part of the generic interface hardware which com.prises the 
twelve channels for page sync, line sync, byte clock, return byte 
clock, and eight video data signals in the parallel mode, or the 
five channels for page sync, line sync, pixel clock, return pixel 
clock, and one video data signal in the serial mode. 
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immediate duplex 
(also simultaneous duplex) 


lOT (Image Output Terminal) 

job 


leading edge 


long edge feed 


marking engine 

mecca 

N-to-1 


octet 

one-to-N (1-to-N) 


page video 

parameter bank 
peer lOT 


pitch (machine pitch) 


pixel 


plate 


A printing process in which both surfaces of a sheet of paper 
are imaged in a single pass past two separate imaging stations 
positioned to image opposite sides of the paper. The imaging 
stations may be directly opposed, in which case the imaging is 
truly simultaneous, or they may be offset along the paper path. 

(Defined in chapter 1) 

At the PSP input; a single Interpress Master file (or equivalent). 
At the lOT Interface and within the lOT; the aggregate of 
parameter banks which describe the processing of all sheets of all 
copy-sets which are to be printed from a single Interpress Master 
(or equivalent). Within the lOT, jobs are categorized as previous, 
current, next, or interrupted. (Refer to section 6.4.3). 

With respect to the Standard Image Frame or to the paper, the 
edge perpendicular to the motion of the Standard Image Frame 
or paper which reaches the transfer station first, or in a direct 
imaging system, reaches the imaging station first. 

Cut-sheet paper feeding system in which the longer edge of the 
paper is perpendicular to the motion of the paper, and the fast 
scan direction is thus parallel to the longer edge. 

The major electro-mechanical sub-system of an lOT which 
converts electrical data to marks on paper. 

See ground mecca. 

Characteristic of a job which indicates that the logical pages of a 
document are delivered to the output destination last page first, 
first page last. This implies that the output sheets are delivered 
face up. 

A group of eight pixels which are contiguous in a scan line. 

Characteristic of a job which indicates that the logical pages of a 
document are delivered to the output destination first page first, 
last page last. This implies that the output sheets are delivered 
face down. 

That image information which is intended to appear on the 
output medium. 

See Bank. 

Defined with respect to a PSP, a peer lOT is one which closely 
matches the performance of the PSP with respect to maximum 
total video data rate, document throughput rate, and data link 
frame processing time. 

The interval between successive recurrences of the same event in 
the imaging cycle of the marking engine. For example, the 
interval between two successive positive transitions of page sync. 
This particular interval is also known as page-time, at the 
interface. Refer to figure 4-1. 

Picture element. At the lOT interface, a binary bit representing 
full density or zero density of one color, typically black, of the 
picture element being represented. For grey scale imaging, 
pixels are composed of 2 to 8 bits representing the density of 
the pixel. The bits of multi-bit pixels are transferred in parallel 
across the interface. (Refer to appendix E.) 

The image information which is applied in one imaging cycle to 
one surface of the output medium (paper). Note that more than 
one plate may be applied to the same surface, in sequential 
imaging cycles, to form a composite image, e.g., a color image 
in which different colors are applied via separate plates. The 


HIGH-END lOT INTERFACE 2.2 


GLOSSARY-3 



GLOSSARY 


PSP (Print Service Processor) 


race track 


ROS 

set 

sheet 


simplex (printing) 


simplex (transmission) 
slow-scan 


stack 


standard image frame 


start of scan edge 


term plate is used when describing the rendering of a particular 
set, or subset, of imaging information, e.g., whether it is 
rendered on the simplex side or duplex side of the sheet, and in 
what color. 

Major element of a printer which accepts image information from 
the larger system in a standard format and converts it to raster 
format and delivers it in real time to the lOT. 

A duplex paper path which does not store sheets, and therefore 
has the characteristic that the Duplex Offset (see 
lotConfiguration, section 6.3.3.) remains constant as the path is 
filled. A Race Track may or may not be capable of loading and 
unloading the reversing station in a single page-time. If not, it 
will require that dead cycles be alternated with the simplex 
imaged sheets as the paper path is filled. (See also storing 
(duplex paper path).) 

Raster Output Scanner. The electro-optical subsystem of a 
marking engine. 

See copy-set 

A single piece of output medium (e.g. paper) which is the 
receptor of an image on one or both of its surfaces. Each image 
may comprise one or more plates. Note that when the output is 
derived from a continuous web, the individual sheets may not 
exist as separate entities until the web is cut. The web may be 
cut just prior to delivery of the sheets to an lOT output device, 
or it may be taken up on an output roll, removed, and cut off¬ 
line. 

Pertaining to a printing operation in which only one side of the 
paper is imaged. In a duplex printing operation, the simplex side 
of the paper is the obverse or front side when the sheet is 
viewed as part of a normal English document. 

Pertaining to a point-to-point transmission system or facility in 
which information is sent in one direction only. 

Applied to the direction or dimension which is parallel to the 
motion of the paper during imaging, i.e. perpendicular to the 
lines of the image raster. 

The aggregate of sheets bearing the same image (or images if 
duplex) as they appear at the output of the iOT. Stacks result at 
the output from multiple replications of a single sheet, or from 
uncollated delivery of multiple replications of a multi-sheet 
document. 

A rectangular image space whose sides are parallel to the slow 
scan and fast scan directions of the IOT and whose dimensions 
are equal to the dimensions of the largest size paper which an 
IOT can accommodate, plus registration tolerance in the 
respective directions. An IOT may be readjustable to implement 
more than one Standard Image Frame. Such readjustment may 
require the machine to be cycled down. 

With respect to the Standard Image Frame or to the paper, the 
edge which is perpendicular to the fast scan direction, and which 
is imaged first in those imaging systems which deliver pixels of 
image raster lines In sequence. In those imaging systems which 
employ line arrays which may image the complete line, or 
segments of the line, simultaneously, it is the edge 
corresponding to the end of the array which is normally loaded 
first with the video data. 
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Storing (duplex paper path) 

task 

total video data rate 
trailing edge 

trilevel hi-lite color 

web feed 


A duplex paper path which temporarily stores simplex imaged 
sheets so that alternate dead cycles are not required when the 
paper path is being filled. A storing duplex paper path has the 
characteristic that the DuplexOffset (see lotConfiguration, 
section 6.3.3.) increments, from the minimum to twice the 
minimum minus 1, as the paper path is filled. See also race 
track. 

Within the lOT, the processing represented by a single parameter 
bank. 

Number of bits per unit of time transferred across the imaging 
interface, whether serially or in parallel. 

With respect to the Standard Image Frame or to the paper, the 
edge perpendicular to the motion of the Standard Image Frame 
or paper which reaches the transfer station last, or in a direct 
imaging system, reaches the imaging station last. 

An imaging technique in which the image for the principal color 
and the image for a single hi-lite color are delivered 
simultaneously to the intermediate imaging medium, and the 
image is developed and transfered in a single pass of the output 
medium. 

Characteristic of an lOT in which the output medium is supplied 
in a continuous web from a roll and is not cut into individual 
sheets until after imaging. The web may be cut just prior to 
delivery of the sheets to an lOT output device, or it may be re- 
rolled, removed, and cut off-line. The width of the web 
corresponds to the fast scan dimension, which is typically the 
length of the final cut-sheet. 
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